RE: c++/8706: gcc cannot generate __cdel functions that can be called by Visual C if that function returns >8 byte strucutres by value

["Cheng, Cheuk" <cheng at powertv dot com>]

Hi, I was just relaying info about this issue and I apologized if I did
not make things clearer.  From the original issue finder went the
following reply.  Please let me know if you need more information.

Thanks,
cheng@powertv.com

--------------------------------
Check the value of the ESP register before and after calling "ret_test"
in the source example.  When compiled with VC, ESP is the same after
returning as it is before.  If compiling with GCC, ESP is different.
Since the caller is supposed to clean up the stack with cdecl, ESP needs
to be the same so that the caller doesn't need knowledge of how the
function was compiled (other than that it is cdecl) in order to clean up
the stack.
--------------------------------


-----Original Message-----
From: cgf@gcc.gnu.org [mailto:cgf@gcc.gnu.org] 
Sent: Wednesday, November 27, 2002 9:25 PM
To: gcc-bugs@gcc.gnu.org
Subject: Re: c++/8706: gcc cannot generate __cdel functions that can be
called by Visual C if that function returns >8 byte strucutres by value


Synopsis: gcc cannot generate __cdel functions that can be called by
Visual C if that function returns >8 byte strucutres by value

Responsible-Changed-From-To: unassigned->cgf
Responsible-Changed-By: cgf
Responsible-Changed-When: Wed Nov 27 21:24:26 2002
Responsible-Changed-Why:
    investigated the problem
State-Changed-From-To: open->feedback
State-Changed-By: cgf
State-Changed-When: Wed Nov 27 21:24:26 2002
State-Changed-Why:
    I don't see any obvious evidence of stack corruption in the assembly
that you produced.  It seems like gcc and msvc produce the same
structure layout and return the address of the structure in the EAX
register.
    
    I tried compiling your test case with one function in MSVC and
another in gcc and the structure was always correctly initialized and
reported.
    
    So, unless you can provide further details, I will close this PR.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=g
cc&pr=8706