This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Sun, Feb 11, 2001 at 04:05:20PM -0800, Geoff Keating wrote:
> > From: "Kevin B. Hendricks" <khendricks@ivey.uwo.ca>
> > Reply-To: khendricks@ivey.uwo.ca
> > Date: Sun, 11 Feb 2001 10:23:49 -0500
> > Cc: gcc-patches@gcc.gnu.org, David Edelsohn <dje@watson.ibm.com>
> > 
> > Hi Geoff,
> > 
> > > I believe it's to allow linking of sysv4 code with eabi code,
> > > primarily to save on multilibs.  STACK_BOUNDARY is the stack alignment
> > > that the compiler can assume, ABI_STACK_BOUNDARY is the stack
> > > alignment that the compiler should preserve.
> > 
> > Okay, can you translate this into English for me ;-)
> 
> Perhaps if I explain what they are used for.
> 
> Stack is (or should be) allocated in chunks of ABI_STACK_BOUNDARY.  So
> if it started off 128-bit aligned, and ABI_STACK_BOUNDARY is 128,
> it'll stay 128-bit aligned.
> 
> 
> STACK_BOUNDARY is used to optimise certain stack pointer operations,
> for instance GCC will convert
> 	addi  r3,r1,4
> to
> 	ori   r3,r1,4
> which it can only do because it knows the stack pointer is aligned.
> 
> > Are you saying that STACK_BOUNDARY should stay at 64?  
> > 
> > If so, do you just want me to change your original libffi code for ppc to 
> > remove the assertions that check for proper stack alignment and adjust the 
> > code to remove the constraint?
> 
> No, because the stack really should be aligned.

Note, when I wrote this code 2-3 years ago, the Linux PowerPC stack was not
aligned properly (it only aligned stacks to 64-bits, not 128 bits).  It has the
side effect of also allow eABI to be linked with ABI, reducing the multilibs.
If it has since been changed, and it is deemed that eABI folk should not
interlink with ABI stuff, then Geoff/Dave can consider nuking
ABI_STACK_BOUNDARY, though obviously anything that runs on a really old Linux
PowerPC system, might see the bug of changing addi's to ori's, which will give
you the wrong address.

> > Or are you saying something is broken in gcc and libffi is correct but we 
> > just don't know where to fix it?
> 
> Yes.  (Mind, a proper bug report would make it much easier to find the
> problem.  You said something about alloca?)
> 
> > Also, since this code will be involved, what is your opinion on changing 
> > return types for small structures to match the true ABI? (given it will 
> > create yet another binary incompatibility).
> 
> I'm generally in favor of doing this, but not at the cost of losing
> backwards binary compatibility.
> 
> -- 
> - Geoffrey Keating <geoffk@geoffk.org>

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]