This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc.c-torture/unsorted/pass.c: what is it supposed to test?


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).

-- 
Joseph S. Myers
jsm@polyomino.org.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]