Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <42C42EE7.2060704@x-ray.at>
Date: Thu, 30 Jun 2005 19:41:59 +0200
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8b) Gecko/20050217
MIME-Version: 1.0
To: "'Cygwin List'" <cygwin AT cygwin DOT com>
Subject: Re: gcc bug: convert_move -O3
References: <SERRANO689cMhtTYDGG000002d2 AT SERRANO DOT CAM DOT ARTIMI DOT COM>
In-Reply-To: <SERRANO689cMhtTYDGG000002d2@SERRANO.CAM.ARTIMI.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Dave Korn schrieb:
> ----Original Message----
>>From: Gerrit P. Haase
>>Sent: 30 June 2005 12:10
>>>>static int hack30_pray(ax, items, func)
>>>>int ax;
>>>>int items;
>>>>void *func;
>>>>{
>>>>    return 0;
>>>>}
>>>>int main () {
>>>>  int ax, items;
>>>>  void * symref;
>>>>  float num;
>>>>  num = ((*((float (*)()) hack30_pray))(ax,items,symref));   return 0;
>>>>}
> 
>>S.th. wrong with your testcase?
> 
>   Absolutely.  There are two *VERY* bad things about that bit of code:
> 
> 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'll write an extra function for the float case. Only gcc dislikes that.

> 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. Both DLL types should be able to be loaded. 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. ;-)
That's why I didn't want to fix perl Win32::API callbacks with that mess.

BTW: I fixed C::Dynalib now at least so we do have another working perl 
FFI with callbacks again.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

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