[Bug target/77687] New: frame access after release without redzone on powerpc

[hainque at gcc dot gnu.org]

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

            Bug ID: 77687
           Summary: frame access after release without redzone on powerpc
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hainque at gcc dot gnu.org
                CC: segher at kernel dot crashing.org
  Target Milestone: ---
            Target: powerpc-elf, powerpc-eabispe

Created attachment 39672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39672&action=edit
testcase

As discussed with Segher at the GNU cauldron this summer,
filing a PR for the problem described and discussed from
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01337.html

The problem is still visible on mainline with a cross compiler
configured for powerpc-elf, on this artificial case
forcing the right combination of internal circumstances:

/* t.c */
void g(int, char *);

const char * dum = "hello";

void f(int x)
{
       char big[200000];
 start:
       g(x, big);
       g(x, big);
       register void *p asm("r11") = &&start;
       asm("" : : "r"(p));
       asm("" : : :"r28");
       asm("" : : :"r29");
       asm("" : : :"r30");
}

./cc1 -O2 t.c -o - -mregnames

        lwz %r11,0(%r1)    # retrieve frame pointer
        ...
        mr %r1,%r11        # release frame
        lwz %r29,-12(%r11) # read from frame
        mtlr %r0
        lwz %r30,-8(%r11)  # ...
        lwz %r31,-4(%r11)  # ...
        blr

I'll attach the patch we have been using locally as
a stop-gap measure.

At some point in the thread, from
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00764.html

Segher suggested:
<< I think the best thing to do is add the clobber-of-mem-scratch to the
final stack deallocate (as a parallel).  I don't see anything else that
will work reliably. >>

I have the start of a patch for this as well (based on gcc-6).
Still missing the definition of the proper insn pattern to recognize
the parallel.

Olivier