This is the mail archive of the
mailing list for the GCC project.
Re: Bug in gcc CVS HEAD from a few days ago with alloca and stack alignment
- To: khendricks at ivey dot uwo dot ca
- Subject: Re: Bug in gcc CVS HEAD from a few days ago with alloca and stack alignment
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Sun, 11 Feb 2001 16:08:15 -0800
- CC: khendricks at ivey dot uwo dot ca, gcc-patches at gcc dot gnu dot org, dje at watson dot ibm dot com, tromey at redhat dot com
- References: <200102110033.TAA37292@mal-ach.watson.ibm.com> <firstname.lastname@example.org> <20010211094511.B14114@redhat.com> <01021114443600.25815@localhost>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> From: "Kevin B. Hendricks" <email@example.com>
> Reply-To: firstname.lastname@example.org
> Date: Sun, 11 Feb 2001 14:44:36 -0500
> Cc: email@example.com, firstname.lastname@example.org,
> David Edelsohn <email@example.com>, firstname.lastname@example.org
> 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.
> 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
- Geoffrey Keating <email@example.com>