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 c++/49073] g++ optimizer breaks do-while code


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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-20 07:50:02 UTC ---
I think the bug is fairly obviously in and_comparisons_1 (and also in
or_comparisons_1), going through a PHI node needs to be done with lots of care.
We have:
<bb 3>:
  # i_1 = PHI <1(2), i_9(6)>
  # f_2 = PHI <0(2), f_10(6)>
  d_6 = a[i_1];
  if (f_2 != 0)
    goto <bb 4>;
  else
    goto <bb 6>;
<bb 4>:
  if (d_6 == 4)
    goto <bb 5>;
  else
    goto <bb 6>;
<bb 5>:
  c.0_7 = c;
  c.1_8 = c.0_7 + 1;
  c = c.1_8;
  goto <bb 7>;
<bb 6>:
  i_9 = i_1 + 1;
  f_10 = d_6 == 3;
  if (d_6 <= 6)
    goto <bb 3>;
  else
    goto <bb 7>;

and_comparisons_1 is called here with f_2 != 0 and d_6 == 4, it sees that
f_2 is a result of a PHI node, and performs as the comment says:
/* If every argument to the PHI produces the same result when
   ANDed with the second comparison, we win.  */
First PHI argument is 0, so it is 0 && d_6 == 4 then, and for the second case
it mistakenly follows on the SSA_NAME argument of the PHI, so f_10 and d_6 == 4
and we recurse into and_comparisons_1 with d_6 == 3 and d_6 == 4, which is of
course false.  The bug is that each of the d_6's is from a different loop
iteration.

So I think we need to give up if PHI argument is an SSA_NAME which might be
defined in a different iteration of a loop, probably some dominance checks
between the bb the PHI is defined and bb where the SSA_NAME is defined.


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