https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2020-08-25
CC| |amker at gcc dot gnu.org,
| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Even not with -ffinite-loops. The reason is that finiteness of loops is
determined by frontends now and recorded in loop->finite_p but the loop
only appears after tail-recursion optimization. I guess tailr could
unconditionally set loop->finite_p since the stack is bounded
but it relies on loop discovery and thus there's no easy way to do this
(not sure if the loop is always natural).
Of course niter analysis might do a better job on this kind of loop
to prove finiteness ...
One reason for the failure is of course that we compute
Analyzing # of iterations of loop 1
exit condition 0 < [(int) ((unsigned int) bytes_7(D) + 4294967232), + , -64]
bounds on difference of bases: -2147483648 ... 2147483647
result:
under assumptions (int) ((unsigned int) bytes_7(D) + 4294967232) <=
2147483584
zero if (int) ((unsigned int) bytes_7(D) + 4294967295) < 0
# of iterations ((unsigned int) bytes_7(D) + 4294967295) / 64, bounded by
33554432
(set_nb_iterations_in_loop = scev_not_known))
which we throw away, not using it for loop estimates / max number of iterations
computation.
