On Wed, Apr 26, 2006 at 08:13:21PM -0400, Tom Lane wrote:
> 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.
That's right, except I read "object", not "primative type". The
question revolves a bit around what an object is. This discussion on
the GCC lists [1] suggests that the syntax a->b is merely syntactic
sugar for (*a).b and thus the "object" being accessed is (*a), the type
of b is not relevent to the decision.
The standard [2] (at least that version) says:
3.14 object
region of data storage in the execution environment, the contents of
which can represent values
So is not limited to primitive types.
> 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.
Well, I imagine it doesn't help that the result of malloc(), which
normally can't alias anything, is assigned to a global variable of a
particular type, and subsequently cast to its actual type.
However, the posters original example doesn't exist in the current
codebase (we never assign T_String to a tag field, only to the type
field), so wherever the problem is, it's not here. At the end of the
day, our use of pointer casts makes the strict-aliasing rules a risk so
we're hardly likely to enable it anytime soon.
Have a nice day,
[1] http://gcc.gnu.org/ml/gcc/2003-02/msg01438.html
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
Quotes from standard:
6.5 Expressions
7 An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
<rules>
6.3.2.1 Lvalues, arrays, and function designators
An lvalue is an expression with an object type or an incomplete type
other than void;
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.