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.
signature.asc
Description: Digital signature
