https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
--- Comment #12 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
We've just been looking at this today for s390x which fails these tests for
various reasons too (actually we've located at least four different Gcc bugs by
looking at this test case). Some of the calculations in
allocate_dynamic_stack_space are weird, but that isn't the issue at hand (I'm
currently working on that).
We were planning to create a new bug report for this, but if it's already being
discussed ... S390x fails the checks "y == 2" probably because the
cprop_hardreg pass does something wrong with the var_location information.
We've only debugged this for "x" yet, but it's probably the same cause for "y".
After reload we have (s390x, -O3 -m64):
-- snip --
(insn 27 26 99 2 (parallel [
(set (reg/f:DI 15 %r15)
(minus:DI (reg/f:DI 15 %r15)
(reg:DI 2 %r2 [73])))
(clobber (reg:CC 33 %cc))
]) pr36728-1.c:12 1409 {*subdi3}
(expr_list:REG_DEAD (reg:DI 2 %r2 [73])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil))))
(insn 99 27 57 2 (set (reg/f:DI 1 %r1 [65])
(plus:DI (reg/f:DI 11 %r11)
(const_int 191 [0xbf]))) pr36728-1.c:10 1075 {*la_64}
(nil))
(insn 57 99 33 2 (set (reg/f:DI 3 %r3 [77])
(reg/f:DI 15 %r15)) pr36728-1.c:12 1073 {*movdi_64}
(nil))
(debug_insn 33 57 6 2 (var_location:DI x (plus:DI (reg/f:DI 3 %r3 [77])
(const_int 160 [0xa0]))) pr36728-1.c:12 -1
(nil))
-- snip --
Insn 27 adjusts the stack pointer, insn 57 copies it to r3 and insn 33 says
that "x" is at "r3 + 160". The following constant propagation pass
(cprop_hardreg) results in
-- snip --
(insn 27 26 99 2 (parallel [
(set (reg/f:DI 15 %r15)
(minus:DI (reg/f:DI 15 %r15)
(reg:DI 2 %r2 [73])))
(clobber (reg:CC 33 %cc))
]) pr36728-1.c:12 1409 {*subdi3}
(expr_list:REG_DEAD (reg:DI 2 %r2 [73])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil))))
(insn 99 27 57 2 (set (reg/f:DI 1 %r1 [65])
(plus:DI (reg/f:DI 11 %r11)
(const_int 191 [0xbf]))) pr36728-1.c:10 1075 {*la_64}
(nil))
(insn 57 99 33 2 (set (reg/f:DI 3 %r3 [77])
(reg/f:DI 15 %r15)) pr36728-1.c:12 1073 {*movdi_64}
(nil))
(debug_insn 33 57 6 2 (var_location:DI x (plus:DI (reg/f:DI 15 %r15 [77])
(const_int 160 [0xa0]))) pr36728-1.c:12 -1
(nil))
-- snip --
It has propagated the value of r15 into insn 33, so now the var_location is now
separated from the place when it actually becomes valid (after insn 27), and
further passes result in bogus DWARF location list for "x".
(This is assembly output with a patch I'm working on; y does not use alloca for
aligmnent; I think this is independent of the bug.)
-- snip --
.LVL0:
stmg %r11,%r15,88(%r15)
aghi %r15,-200
lgr %r11,%r15
.loc 1 12 0
aghi %r2,14
.LVL1:
nill %r2,65528
sgr %r15,%r2 <== set final value of stack pointer
.loc 1 15 0 <== location list for "x" should start here
lhi %r2,2
.loc 1 10 0
la %r1,191(%r11)
.LVL2: <== where location list for "x" actually starts
nill %r1,65504 <==
.loc 1 16 0 <== location list for "y" should start here
larl %r4,b
.loc 1 17 0
mvi 160(%r15),25
.loc 1 12 0
la %r3,160(%r15)
.LVL3:
.loc 1 18 0
larl %r5,a
.loc 1 15 0
st %r2,0(%r1)
.loc 1 16 0
...
-- snip --
Without checking the details for "y" yet we've noticed that there is no
location list for y in the DWARF info, so gdb happily prints random data from
the stack slot with "p y" when stopping at the first ".loc 1 16 0".
