[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[tuliom at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85894

--- Comment #2 from Tulio Magno Quites Machado Filho <tuliom at linux dot ibm.com> ---
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)
> 0x00003fffb7fb0908 <foo+20>:	stdu    r1,-128(r1)

The stack frame starts with 128B

> B+>0x00003fffb7fb092c <+56>:	stdu    r9,-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 0x3fffffffefd0 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
> 0x3ffffffff0e0 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 <foo+96>         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.