http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-07
12:54:35 UTC ---
I expect this to be a major nuisance on our users for 4.8. And I don't see
a good way to solve this issue!
For the testcase in comment#8 we warn during early VRP but not from late VRP.
OTOH I'd rather disable the second VRPs array bound warnings ...
What would be interesting to see is if there is a way for VRP to prove
(after the unrolling happened) that the access is dead. For the testcase
in comment#8 something magic happens for a[3] (no warning) vs. a[4] (warning).
Maybe we should refrain from doing the speculative new complete unrolling
during cunrolli?
OTOH what happens in VRP for int a[4] case is that it estimates the number
of iterations of the outer (not unrolled) loop to be 4, one too large:
Analyzing # of iterations of loop 1
exit condition [0, + , 1] < n_8
bounds on difference of bases: 0 ... 4294967295
result:
# of iterations n_8, bounded by 4294967295
Statement (exit)if (i_2 < n_8)
is executed at most n_8 (bounded by 4294967295) + 1 times in loop 1.
here # of iteration analysis does not take into account that n_8 is [0, 3]
already. Of course there is no good way to feed it this information
(we are currently iterating and not conservative!) without re-computing
number of iterations and SCEV all the time (that was shot down to be very
much too time consuming).
