[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug

[mkuvyrkov at gcc dot gnu.org]

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).