http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, looks like a very old patch in my dev tree fixes this (though reverting it
doesn't make it reproduce on trunk):

Index: tree-predcom.c
===================================================================
--- tree-predcom.c      (revision 204397)
+++ tree-predcom.c      (working copy)
@@ -1410,9 +1410,11 @@ ref_at_iteration (struct loop *loop, tre
        }
       else
        {
-         val = fold_build2 (MULT_EXPR, type, iv.step,
-                            build_int_cst_type (type, iter));
-         val = fold_build2 (PLUS_EXPR, type, iv.base, val);
+         tree itype = signed_type_for (type);
+         val = fold_build2 (MULT_EXPR, itype, fold_convert (itype, iv.step),
+                            build_int_cst (itype, iter));
+         val = fold_build2 (PLUS_EXPR, itype,
+                            fold_convert (itype, iv.base), val);
        }
       *idx_p = unshare_expr (val);
     }

but the above is a hack - we get

  <bb 6>:
  _27 = c.1_6 + 4;
  _24 = c.1_6 + 4;
  _23 = e[_27][-2];
  _32 = e[_24][-1];

instead of

  <bb 6>:
  _27 = c.1_6 + 4;
  _24 = c.1_6 + 4;
  _23 = e[_27][4294967294];
  _32 = e[_24][4294967295];

still this looks somewhat familiar to me ...

Reply via email to