------- Comment #1 from davem at gcc dot gnu dot org 2010-02-09 22:08 -------
Ok, I now know a lot more about this bug. It's effects were masked
before gcc-4.4 because we used to have the TFmode secondary reload
slot in every stack frame. That got removed by my commit:
2009-01-04 David S. Miller <da...@davemloft.net>
* config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED_RTX): Delete.
(STARTING_FRAME_OFFSET): Always set to zero.
The problem case is where the stack frame (with bias added) is only 8-byte
aligned. The allocate_dynamic_stack_space() code ends up emitting (after
optimizations clean it up) something like:
0x10000010b00 <_dl_fini+864>: add %i5, 0xf, %g4
0x10000010b04 <_dl_fini+868>: and %g4, -16, %g4
0x10000010b08 <_dl_fini+872>: sub %sp, %g4, %sp
0x10000010b0c <_dl_fini+876>: add %sp, 0x8be, %i2
0x10000010b10 <_dl_fini+880>: b %xcc, 0x100000108bc <_dl_fini+284>
0x10000010b14 <_dl_fini+884>: and %i2, -16, %i2
%i5 is the desired alloca length, and %i2 is the final alloca() buffer
pointer.
Consider a start condition such as:
%sp: 0x7feffffe399 + 2047 (BIAS) == 0x7feffffeb98
%i5: 0x20
We'll end up with a final %i2 value:
alloca area calculation:
$i2 = (%sp + 0x8be) (0x8b3 == 2047 + 176 + 15)
0x7feffffec37
$i2 &= -16
0x7feffffec30
And this 0x7feffffec30 which is %sp + BIAS + 0xb8,
or 184 decimal into the stack frame.
We're supposed to use stack_frame + 176 decimal. But
because of the way we've had to 16-byte align the final
pointer, we're now overflowing into the local variable
stack slots.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43004
