http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu.org
--- Comment #4 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
The underlying bug appears to be in CSA (combine-stack-adj.c) and I would
appreciate Richard's insight on how to fix it.
Summary: CSA merges stack variable into global one, and then alias analysis
thinks that ex-stack-now-global variable does not overlap with global
variables.
After patch in rev. 162592 code hoisting becomes able to simplify code just a
bit, which causes scheduler to generate a different sequence, exposing a latent
bug.
During expand we have:
# BLOCK 3 freq:3900
# PRED: 2 [39.0%] (true,exec)
1 D.2750 = x6;
goto <bb 5>;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 4 freq:6100
# PRED: 2 [61.0%] (false,exec)
D.2750 = x7;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 5 freq:10000
# PRED: 4 [100.0%] (fallthru,exec) 3 [100.0%] (fallthru,exec)
2 x8 = D.2750;
3 x6.x2 = 1;
D.2733_1 = x8.x2;
printf ("%d\n", D.2733_1);
CSA combines stack variable D.2750 in insn (1) into global x6, but fails to
update uses of D.2750. After CSA DECL_RTL of MEM in insn (2) still references
D.2750 even though it now reads directly from x6. Because D.2750 is on stack
and x6 is global -- alias analysis (nonoverlapping_memrefs_p()) tells scheduler
that it is OK to move insn (3) before insn (2).
