https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 386d5732ea0..9d9939642f6 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14208,11 +14208,7 @@ multiple_of_p (tree type, const_tree top, const_tree
bo
ttom, bool nowrap)
              && multiple_of_p (type, TREE_OPERAND (top, 2), bottom, nowrap));

     case INTEGER_CST:
-      if (TREE_CODE (bottom) != INTEGER_CST
-         || integer_zerop (bottom)
-         || (TYPE_UNSIGNED (type)
-             && (tree_int_cst_sgn (top) < 0
-                 || tree_int_cst_sgn (bottom) < 0)))
+      if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
        return 0;
       return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
                                SIGNED);

of course makes most sense there.  I'm evaluating what

diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..2305e1d53f6 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -986,6 +986,7 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
                         bool exit_must_be_taken, bounds *bnds)
 {
   tree niter_type = unsigned_type_for (type);
+  tree stype = signed_type_for (niter_type);
   tree s, c, d, bits, assumption, tmp, bound;
   mpz_t max;

@@ -1051,10 +1052,8 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
      along with condition 1) or 1').  */
   if (!niter->control.no_overflow
       && (integer_onep (s)
-         || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
-                            false)
-             && multiple_of_p (type, fold_convert (niter_type, final), s,
-                               false))))
+         || multiple_of_p (stype, fold_convert (stype, c),
+                           fold_convert (stype, iv->step))))
     {
       tree t, cond, relaxed_cond = boolean_false_node;


will yield since we are interpreting iv->step as signed.  Pointers are
what makes this all a bit awkward since for those iv->base is a pointer
but iv->step is (unsigned) sizetype to be interpreted as signed.

Anyway, I do appreciate the extended test coverage we are getting from
the auto-generation of valid code people!

Reply via email to