https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674
Bug ID: 70674
Summary: [4.9/5/6 regression] S/390: Memory access below stack
pointer in epilogue
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 38276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38276&action=edit
Fix proposal
t.c:
void foo (void) { volatile int a = 5; (void) a; }
cc1 -O2 -fno-omit-frame-pointer -march=z10 -mtune=z196 t.c
The assignment to a is moved by the scheduler *after* the stack pointer
restore. While not being a problem in this example in other circumstances this
might cause data corruption if e.g. a signal handler gets triggered in between.
foo:
ldgr %f2,%r11
ldgr %f0,%r15
lay %r15,-168(%r15)
lgr %r11,%r15
lgdr %r15,%f0 <----- stack pointer restore
mvhi 164(%r11),5 <----- stack write for variable a
l %r1,164(%r11)
lgdr %r11,%f2
br %r14
The variable access is done through the framepointer which does not conflict
with the restore of r15.
The problem was latent in the backend but was so far hidden by doing the
restore of r11 and r15 in the same instruction - a load multiple. However,
there always was the potential problem of doing the stack access with a
temporary register assigned by the compiler.
