This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/53465] [4.7 regression] wrong code with -O1 -ftree-vrp


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-24 07:21:28 UTC ---
We have
  x_9 = *D.1724_8;
...
  x_16 = ASSERT_EXPR <x_9, x_9 != 0>;
  D.1726_10 = found_x_2 != 0;
  D.1727_11 = x_16 <= prev_x_3;
...
  # found_x_2 = PHI <0(2), 1(6)>
  # prev_x_3 = PHI <prev_x_4(D)(2), x_16(6)>
...
  loop to top

prev_x_3: ~[0, 0]  EQUIVALENCES: { x_9 } (1 elements)
prev_x_4(D): UNDEFINED
x_9: VARYING
x_16: ~[0, 0]  EQUIVALENCES: { x_9 } (1 elements)

I think the problem are the equivalences, or their handling.  When we merge on
PHI UNDEFINED with ~[0, 0] EQUIVALENCES: { x_9 } into the latter, we push the
equivalence into the next loop iteration where x_9 already can have a different
value.  I guess either we could drop all equivalences when merging UNDEFINED
with some range with EQUIVALENCES, or at least those equivalences which don't
dominate the PHI.  Richard, what do you think?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]