Re: ANSI-strict pointer aliasing rules - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ANSI-strict pointer aliasing rules
Date
Msg-id 1920.1146096801@sss.pgh.pa.us
Whole thread Raw
In response to Re: ANSI-strict pointer aliasing rules  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: ANSI-strict pointer aliasing rules  (Greg Stark <gsstark@mit.edu>)
Re: ANSI-strict pointer aliasing rules  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> In the grandparent's case I think
> the compiler is being really stupid because it can know the two
> pointers are the same. But I'm sure there are more subtle cases where
> it won't know. PostgreSQL typecasts pointers fairly freely.

Actually, if xlc is behaving as Taral says then I'm pretty convinced
it's *broken*; it is assuming far more than is allowed even by the ANSI
aliasing rules.  As I read the spec, ANSI aliasing says that a given
value must always be accessed through equivalent (up to signedness)
primitive types, ie, if you store through an int pointer and fetch
through a long pointer the compiler is allowed to reorder those two
references.  In the example Taral gives, both field references are to
fields of type NodeTag.  I don't see anything in the spec that allows
the compiler to assume they are distinct variables just because they are
members of different struct types.  The spec restriction is defined in
terms of the lvalue type of the particular store or fetch access, not on
what kind of structure it's part of.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Catalog Access (was: [GENERAL] Concurrency problem
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: GIN - Generalized Inverted iNdex. Try 2.