https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85894
--- Comment #2 from Tulio Magno Quites Machado Filho ---
I don't think this is a bug. At least not an alloca() bug.
Let me explain:
(In reply to Rogerio Alves from comment #0)
> 0x3fffb7fb0908 : stdur1,-128(r1)
The stack frame starts with 128B
> B+>0x3fffb7fb092c <+56>: stdur9,-272(r1)
Increases to 128+272 = 400B.
Which I think is more than enough for this function.
> Notice, that stdu r9,-272(r1) move the stack pointer to alloca(te) the space
> on the stack. Now $r1 (stack pointer) is 0x3fffefd0 on my tests.
So, TOC, LR, CR and the backchain are stored in this new place.
There used to be a code copying these values to the new place, but as this
function never returns, the compiler is not copying the values to the new
place.
I don't think this optimization is wrong, though.
Copying the values to the new place wouldn't help anyway because the code
before alloca() still expects these values to be in their old place.
> After the 3th iteration he will execute the code above on address
> 0x30e0 which is the caller stack frame (previous sp) and will set
> the 32 bits after with zeros.
This is the old place of the backchain. It's now reserved for alloca().
So, looks good to me.
> The caller stack frame is gone and when
> longjmp executes we get a Segmentation Fault at:
>
> 0x3fffb7fb0954 ld r2,24(r1)
This is loading 0 because of glibc bug #21895, where the TOC pointer is not
restored in the stack frame for static programs.
That's why the the segfault happens.
