RE: gcc bug: convert_move -O3

["Dave Korn" <dave dot korn at artimi dot com>]

----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/