[PATCH] Fix PR24851 (2nd version)

Richard Guenther rguenther@suse.de
Wed Nov 16 09:44:00 GMT 2005


On Wed, 15 Nov 2005, Ian Lance Taylor wrote:

> Richard Guenther <rguenther@suse.de> writes:
> 
> > On Tue, 15 Nov 2005, Richard Guenther wrote:
> > 
> > > I have a patch along Andrews that fixes both testcases.  I'll post it as
> > > soon as testing finishes.
> > 
> > Here it is.  It fixes fold and fold_stmt to use signed division in
> > recombining pointer + offset to an ARRAY_REF.  I'm not sure this is
> > a correct fix, but it passes bootstrap and regtesting (32 and 64 bit)
> > on x86_64-unknown-linux-gnu for all default languages.
> 
> It seems to me that this is a small problem with our representation.
> p[-1] where p is a pointer ought to be represented as a pointer plus a
> signed value.  p[0xffffffff] ought to be represented as a pointer plus
> an unsigned value.  Right now both cases are represented as a pointer
> plus an unsigned value, because we want PLUS_EXPR to use the same type
> for both operands, and pointers are treated as an unsigned type.

Yes, that analysis is correct.  Note that the C frontend patch basically
tries to avoid the situation by not splitting p[q] to p + q (for this
testcase of course, you still can manually trigger the situation).

One day we might have a well-defined type system in the middle-end which
should disallow pointer addition, but handle pointer + integer offset,
just like the C standard defines things.  This would avoid all this mess.

(So, do you think the '???' comment in the patch is bogous or is it a
valid concern?)

Thanks,
Richard.



More information about the Gcc-patches mailing list