Re: fold: &a[i1] + c * i2 -> &a[i1 + i2] messing up types

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On Wed, 9 Feb 2005, Zdenek Dvorak wrote:

> Hello,
>
> > > > I get an ICE with the following C++ testcase:
> > > >
> > > > void bar(unsigned int i)
> > > > {
> > > >         int a[4];
> > > >         char *p = (char*)&a[1] + 4*i;
> > > > }
> > > >
> >
> > > however the cast should be done using fold_convert:
> > >
> > >  tem = try_move_mult_to_index (TREE_TYPE (arg0), PLUS_EXPR, arg0, arg1);
> > >  if (tem)
> > >    return fold (fold_convert (type, tem));
> >
> > Ok, I prefer changing try_move_mult_to_index, though, as it touches
> > less places.  I'm currently boostrapping and testing the following patch:
>
> I don't think it is a good idea.  TYPE argument of
> try_move_mult_to_index really should be type of the arguments it works
> with, or you are creating a nasty hack and source for other possible
> bugs.

Well, the type argument is only used for constructing the ADDR_EXPR
which has to match TREE_TYPE (addr) due to checking constraints.  So
we could equally omit that argument.  Or give it the meaning I read
into the functions comment:

/* Tries to replace &a[idx] CODE s * delta with &a[idx CODE delta], if s
is
   step of the array.  TYPE is the type of the expression.  ADDR is the
address.
   MULT is the multiplicative expression.  If the function succeeds, the
new
   address expression is returned.  Otherwise NULL_TREE is returned.  */

namely, that we want a tree of type "type" which is the type of the
whole expression, not of the ADDR_EXPR.  But just working around this
possible redundant argument in the callers seems wrong to me, too.

If you prefer removing the type argument that would be fine, too.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/