[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

["rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #7 from rguenth at gcc dot gnu dot org  2006-04-27 15:47 -------
One thing is, that find_interesting_uses_address () produces bases that look
like &(&a[0])->s.  I.e. they are not folded during IV base insertion via

      if (!for_each_index (&base, idx_find_step, &ifs_ivopts_data)
          || zero_p (step))
        goto fail;

Also we don't see that *&a[0] is an ARRAY_REF in idx_find_step, which may cause
other problems.

Another problem is that we record both

(const Foo*)&a[0]

and

&a[0]

as biv's which confuses IVOPTs a lot.

Stripping useless type conversions during biv discovery and folding after the
substitution above fixes the two problems.  What remains is the use of an
out-of-bound array index and a (useless) offset:

<bb 2>:
  ivtmp.39_2 = &x[1];

  # ivtmp.39_4 = PHI <ivtmp.39_1(4), ivtmp.39_2(2)>;
<L0>:;
  D.2068_10 = (int *) ivtmp.39_4;
  MEM[base: D.2068_10, offset: -4B]{this->s} = 1;
  ivtmp.39_1 = ivtmp.39_4 + 4B;
  if (ivtmp.39_1 != &x[5]) goto <L5>; else goto <L2>;

here I do not see how IVOPTs decided that using &x[1] as base is better
than &x[0] (well, the cost for the former is 1 while for the latter is 2(!?)

I have a patch for the first two problems in testing.


-- 


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