Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: "'Cygwin List'" Subject: RE: gcc bug: convert_move -O3 Date: Thu, 30 Jun 2005 18:55:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <42C42EE7.2060704@x-ray.at> Message-ID: Note-from-DJ: This may be spam ----Original Message---- >From: Reini Urban >Sent: 30 June 2005 18:42 >> 1) The function call is through a pointer-to-function-returning float, >> but the function itself returns a void *. This is likely to screw up >> the x87 FP stack when the caller pops a return value that the callee >> didn't push. > > If it's really coming from the SP(0), which gcc obviously assumes > (hard-floats) vs. some other cpu's/clib's return floats on eax > (soft-floats) or just emulates the SP. I said "likely", because I'm not 100% sure, and particularly because I don't know what __fastcall does with the FP stack, nor how it might interact with SSE and other options. There are too many variable factors for me to be confident, but that argues even more strongly against trying anything tricky! > I'll write an extra function for the float case. Only gcc dislikes that. As long as the extra function (I guess you're thinking of a wrapper that will call out to the original one we're discussing) is of the exact same signature as the pointer through which you're calling it, that would be fine. >> 2) Also, the function call is through a >> pointer-to-function-taking-stdargs, but the function itself is not a >> stdargs function. Given the wrong calling conventions, this is liable >> to lead to both caller *and* callee cleaning the args off the stack..... > > Calling conventions should be determined at run-time who will pop the > stack. Sorry Reini, this sentence doesn't make sense to me. AFAIUI, who will pop the stack is determined at compiletime, according to whether the compiler outputs a plain "ret" or a ret with a size-to-pop at the end of the callee-function, and according to whether it emits code at the call site to adjust %esp or not. > Both DLL types should be able to be loaded. Now you've really lost me. Are you saying that this particular dll gets built in two versions using different calling conventions? I don't understand here. >So the hack src > should duplicate itself for both ways. > E.g. WinAPI (pascal = stdcall convention) will fail with the current > hack30 library. > >> A name like 'hack*_pray' suggests that this is an ugly hack that the >> author was praying was going to work..... I am obliged to agree! > > Yes, that's the hairy hack30 trick from unknown old sources, which is > used for several FFI's as last resort. ;-) Yep, well, get rid of it. It's no longer just hairy; it's *so* invalid that Gcc will replace all your function calls with a simple invocation of abort (), which is not what you want! cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/