[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.