Bug in gcc CVS HEAD from a few days ago with alloca and stack alignment

[Geoff Keating]

> From: "Kevin B. Hendricks" <khendricks@ivey.uwo.ca>
> Reply-To: khendricks@ivey.uwo.ca
> Date: Sun, 11 Feb 2001 14:44:36 -0500
> Cc: khendricks@ivey.uwo.ca, gcc-patches@gcc.gnu.org,
>         David Edelsohn <dje@watson.ibm.com>, tromey@redhat.com
> 
> Hi Geoff,
> 
> On a related matter, the libffi code does not follow the sysv abi for passing 
> long long ints in specific register pairs.
> 
> As I understand things (please correct me if I am wrong!) only the following 
> register pairs may be used (r3,r4), (r5,r6), (r7,r8), (r9,r10) to pass long 
> long ints under the sysv abi.

Yes, it has to be 64-bit aligned starting at r3.

> The current code in libffi/src/powerpc/ffi.c does not do this.  It simply 
> packs it into registers not looking at the starting register.
> 
> When I submit my patch to add the closures code for gcj/gij, I will fix this. 

Please do.

> The ffitest.c code never caught this since it only tested passing and 
> returning one long long int which was always the first parameter (so always 
> stored in (r3,r4).

... and add more tests, of course.

> Also, one other ABI interpretation question: when passing arguments, if r9 is 
> used to say pass an int 32, and then we next pass a long long int (it must be 
> stored on outgoing parameter stack since insufficient room), and finally 
> another int32 is passed, should it be stored in r10 or on the parameter stack?

I believe that it goes on the stack.  r10 has been skipped.

> > I'd think you'd want to use PREFERRED_STACK_BOUNDARY then,
> > instead of inventing a target-specific macro.

That sounds like a good idea.  The rs6000 backend predates
PREFERRED_STACK_BOUNDARY.

-- 
- Geoffrey Keating <geoffk@geoffk.org>