[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne

[rguenth at gcc dot gnu.org]

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.