https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
I _think_ that the proper fix is to _not_ code-gen additional loop guards
because we can't possibly get the PHIs correct there. Iff a loop needs a guard
then it will be present before. So the only case we'd need an extra guard is
when the loop didn't have do { } while () style but we reject that case in
can_represent_loop_1 because there we require that number_of_latch_executions
is scev-analyzable. But SCEV doesn't handle niters like
n_6(D) > 0 ? (unsigned int) n_6(D) + 4294967295 : 0
that is, we effectively reject ->may_be_zero.
Testing patch to remove the additional conditions (it passed SPEC CPU 2006 w/o
any issues in a train run).
