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 ...