https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> --- > 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). We used to have discussions about this. We also consider function possibily infinite if it is self recrusive even though it self-recurses finitely many times. I think relying on finiteness of stack is safe assumption and in both cases we should mark loops as finite, but there was some concerns from the C++ developers (Mark Mitchell https://gcc.gnu.org/legacy-ml/gcc/1999-08/msg00700.html) I think we could indeed in both cases (pure-const and tail recursion) assume finiteness based on finiteness of the stack. Honza > > 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. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
