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