[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