[Bug tree-optimization/46970] [4.3/4.4/4.5/4.6 Regression] wrong code with -Os -ftree-loop-linear

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-17 16:17:39 UTC ---
I think the bug is in that gcc_loop_to_lambda_loop doesn't record whether the
SSA_NAME compared in the exit condition was the induction var or incremented
induction var.
E.g. on ltrans-3.c testcase we have
<bb 5>:
  # j_25 = PHI <j_15(4), 0(9)>
...
  j_15 = j_25 + 1;
  if (N.2_3 > j_15)
    goto <bb 4>;
  else
    goto <bb 6>;
and thus the exit condition tests the incremented iv (gcc_loop_to_lambda_loop
btw. doesn't bother to check whether the def stmt of the rhs of exit condition
here actually increments by step, and doesn't bother to check that step fits
into int (so I guess step like 0x100000001ULL would cause trouble).
It just records lower bound 0, upper bound N.2_3 - 1 here and step 1.
But with -Os -ftree-loop-linear on this testcase we have before ltrans:
  j_12 = j_2 + 1;

<bb 4>:
  # j_2 = PHI <0(7), j_12(3)>
  if (j_2 < n_5(D))
    goto <bb 3>;
  else
    goto <bb 5>;
Here similarly it records lower bound 0, upper bound n_5 - 1 and step 1.
But there is an important difference in between the two.
In the former case we correctly use
  gimple_cond_set_condition (exitcond, testtype, newupperbound, ivvarinced);
but we use it in the second case too, which is wrong.