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

[Kevin B. Hendricks <khendricks at ivey dot uwo dot ca>]

Hi Franz,

I have been helping the gcj effort with the ppc closure code in libffi to 
help get the gij (java interpreter running for ppc linux) and have run into a 
problem where after a call to alloca the stack pointer r1 is no longer 
aligned to 16 as the ABI states.

Here is the source code in question taken from java_raw_api.c

void ffi_java_raw_call (/*@dependent@*/ ffi_cif *cif, 
                   void (*fn)(), 
                   /*@out@*/ void *rvalue, 
                   /*@dependent@*/ ffi_raw *raw)
{
  void **avalue = (void**) alloca (cif->nargs * sizeof (void*));
  ffi_java_raw_to_ptrarray (cif, raw, avalue);
  ffi_call (cif, fn, rvalue, avalue);
}

Here is the disassembled code.

Dump of assembler code for function ffi_java_raw_call:
0xfef9ce8 <ffi_java_raw_call>:	stwu	r1,-32(r1)
0xfef9cec <ffi_java_raw_call+4>:	mflr	r0
0xfef9cf0 <ffi_java_raw_call+8>:	stw	r0,36(r1)
0xfef9cf4 <ffi_java_raw_call+12>:	stw	r28,16(r1)
0xfef9cf8 <ffi_java_raw_call+16>:	mr	r28,r3
0xfef9cfc <ffi_java_raw_call+20>:	lwz	r9,4(r28)
0xfef9d00 <ffi_java_raw_call+24>:	lwz	r0,0(r1)
0xfef9d04 <ffi_java_raw_call+28>:	rlwinm	r9,r9,2,0,29
0xfef9d08 <ffi_java_raw_call+32>:	stw	r26,8(r1)
0xfef9d0c <ffi_java_raw_call+36>:	addi	r9,r9,22
0xfef9d10 <ffi_java_raw_call+40>:	stw	r27,12(r1)
0xfef9d14 <ffi_java_raw_call+44>:	rlwinm	r9,r9,0,0,28
0xfef9d18 <ffi_java_raw_call+48>:	stw	r29,20(r1)
0xfef9d1c <ffi_java_raw_call+52>:	neg	r9,r9
0xfef9d20 <ffi_java_raw_call+56>:	stw	r31,28(r1)
0xfef9d24 <ffi_java_raw_call+60>:	mr	r31,r1
0xfef9d28 <ffi_java_raw_call+64>:	mr	r27,r4
0xfef9d2c <ffi_java_raw_call+68>:	stwux	r0,r1,r9
0xfef9d30 <ffi_java_raw_call+72>:	mr	r26,r5
0xfef9d34 <ffi_java_raw_call+76>:	addi	r29,r1,23
0xfef9d38 <ffi_java_raw_call+80>:	mr	r4,r6
0xfef9d3c <ffi_java_raw_call+84>:	rlwinm	r29,r29,0,0,27
0xfef9d40 <ffi_java_raw_call+88>:	mr	r5,r29
0xfef9d44 <ffi_java_raw_call+92>:	bl	0xffe691c <objects+7780>
0xfef9d48 <ffi_java_raw_call+96>:	mr	r6,r29
0xfef9d4c <ffi_java_raw_call+100>:	mr	r3,r28
0xfef9d50 <ffi_java_raw_call+104>:	mr	r4,r27
0xfef9d54 <ffi_java_raw_call+108>:	mr	r5,r26
0xfef9d58 <ffi_java_raw_call+112>:	bl	0xffe77cc <objects+11540>
0xfef9d5c <ffi_java_raw_call+116>:	lwz	r11,0(r1)
0xfef9d60 <ffi_java_raw_call+120>:	lwz	r0,4(r11)
0xfef9d64 <ffi_java_raw_call+124>:	lwz	r26,-24(r11)
0xfef9d68 <ffi_java_raw_call+128>:	lwz	r27,-20(r11)
0xfef9d6c <ffi_java_raw_call+132>:	mtlr	r0
0xfef9d70 <ffi_java_raw_call+136>:	lwz	r28,-16(r11)
0xfef9d74 <ffi_java_raw_call+140>:	lwz	r29,-12(r11)
0xfef9d78 <ffi_java_raw_call+144>:	lwz	r31,-4(r11)
0xfef9d7c <ffi_java_raw_call+148>:	mr	r1,r11
0xfef9d80 <ffi_java_raw_call+152>:	blr
End of assembler dump.

I set breakpoints upon entry to the routine and after the stuwx command that 
updates r1 after the stack has grown.

Breakpoint 12, 0xfef9cf0 in ffi_java_raw_call (cif=0x100a1b1c, fn=0x7f7fee9c, 
    rvalue=0x100a5b34, raw=0x7f7fee9c)
    at ../../../gcc/libffi/src/java_raw_api.c:225
225	{
starting frame pointer r1 is 7f7fec70  

(The above shows upon entry r1 is aligned to 16)


Breakpoint 13, ffi_java_raw_call (cif=0x10077ca0, 
    fn=0xfd5c6ac <_ZN4java4lang6ObjectC2Ev>, rvalue=0x100a5b34, 
raw=0x7f7fee9c)
    at ../../../gcc/libffi/src/java_raw_api.c:225
225	{
but now R1 is 7f7fec58

But now (and for all subsequent calls it is alinged on 8 which is incorrect.

This really messes up the libffi code and closure code which assumes that the 
stack pointer is always aligned to 16.


I don't know whether this is a an implementation issue in alloca but either 
way the the code is missing to round up r9 to the nearest power of 16.


This problem has me stumped in debugging the closure code and was causing 
certain tests to fail when the alloca function allocated a multiple of 8 
instead of a multiple of 16.

I can provide the latest ppc closure code for libffi if you want to recreate 
the problem first hand.

Again, this is with gcc head from Thursday afternoon.

Any help would be greatly appreciated.

Thanks,

Kevin