https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- The bug was made latent by g:51d464b608b38b9e2007948d10b1e0f1dcec142c which ensured that /* If the loop exits immediately, there is nothing to do. */ tree tem = fold_binary (code, boolean_type_node, iv0->base, iv1->base); if (tem && integer_zerop (tem)) { if (!every_iteration) return false; niter->niter = build_int_cst (unsigned_type_for (type), 0); niter->max = 0; return true; } triggered, folding (_2 + 4294967272) + 12 < _2 + 4294967272 to false. That's the following part of the revision, and it probably triggers when doing expand_simple_operations. diff --git a/gcc/match.pd b/gcc/match.pd index 84c9b918041..f5dcbf32bc7 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -2143,6 +2143,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (simplify (pointer_plus (pointer_plus:s @0 @1) @3) (pointer_plus @0 (plus @1 @3))) +#if GENERIC +(simplify + (pointer_plus (convert:s (pointer_plus:s @0 @1)) @3) + (convert:type (pointer_plus @0 (plus @1 @3)))) +#endif /* Pattern match It does seem to me that niter analysis relies on statically detecting not rolling loops, at least for the cases we assume no overflow happens and we use number_of_iterations_lt_to_ne. I can't convince myself that only INTEGER_CST appearant negative delta are problematic for pointer types (which we always assume to have no overflow), but that would be the most simplistic solution here. Still "negative" delta values should be problematic for all cases, and since we only restrict us to constant modulo, delta can also be non-constant.