Re: ANSI-strict pointer aliasing rules

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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.