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

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