This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc.c-torture/unsorted/pass.c: what is it supposed to test?
On Fri, 2004-02-27 at 12:41, Joseph S. Myers wrote:
> On Fri, 27 Feb 2004, Diego Novillo wrote:
>
> > But the real question that the aliasing code is interested in is: Can
> > the intptr_t object be dereferenced? If yes, then we should represent
> > intptr_t objects as pointers in GIMPLE. We can't make these language
> > dependent assumptions inside the optimizers.
> >
> > If not, then treating address assignments to intptr_t as escaping is
> > still the right thing to do.
>
> intptr_t (or any other sufficiently wide integer type) can be cast back to
> the original pointer type and then dereferenced. (The only standard
> guarantee is as regards intptr_t and uintptr_t and void *; otherwise the
> conversions are implementation-defined. GCC documents in extend.texi how
> this implementation defines it, and that integer arithmetic must not be
> used to escape the original object if the integer is cast back to a
> pointer. A typical legitimate use might be to mask off some low-order
> bits of the integer to ensure alignment.)
>
> intptr_t objects themselves are just integers, and casting to them should
> probably be treated as escaping unless it can be trivially optimised away
> (it can be seen that the integer is only ever used for trivial arithmetic
> after which it is converted back to a pointer).
>
Thanks. Hmm, I think we will need to represent intptr_t as pointers in
GIMPLE. All our alias analysis hinges on POINTER_TYPE_P returning
nonzero. Jason, thoughts?
Diego.