http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52754
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-30 11:41:35 UTC --- On Fri, 30 Mar 2012, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52754 > > --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-30 > 11:31:58 UTC --- > (In reply to comment #7) > > Created attachment 27042 [details] > > alternative patch > > I'm not against it, but what if the source code and/or some other pass result > in similar ARRAY_REF? To me pcom still looks potentially buggy... If that happens the other pass is broken or the source invokes undefined behavior. I had the following patch which fixed the issue, too: Index: tree-predcom.c =================================================================== --- tree-predcom.c (revision 186007) +++ tree-predcom.c (working copy) @@ -1414,9 +1414,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); } as we know iter is negative. We could also change the caller so we pass a positive count and instead subtract it from the base value, though that's still going to get possibly negative (and in case iv.base is not a constant we will not know this here). The above would not be a real fix, instead we would need to cater for a large unsigned iv.base, thus, promote val and iv.base to [u]intptr_t. But - we can't really "win" here for array indices that ultimatively will be out-of-bound. If some GCC pass re-constructs invalid array-refs it has to be fixed.
