Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown

Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: This GCC options will be the default in GCC 2.95 and above -fstrict-aliasing Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an unsigned int can alias an int, but not a void* or a double. A character type may alias any other type. Pay special attention to code like this: union a_union { int i; double d; }; int f() { a_union t; t.d = 3.0; return t.i; } The practice of reading from a different union member than the one most recently written to (called "type-punning") is common. Even with `-fstrict-aliasing', type-punning is allowed, provided the memory is accessed through the union type. So, the code above will work as expected. However, this code might not: int f() { a_union t; int* ip; t.d = 3.0; ip = &t.i; return *ip; } Basically this changes the interpretation of "implementation defined" in GCC from "for some reason ANSI didn't codify the normal Unix C thing to do but we will do it anyway" to "screw you". This setting breaks for instance the Linux networking code which plays all kinds of pointer tricks. The thread on the egcs mailing lists contains such gems as "C is not a portable assembly language anymore", "simply use unions", "everybody has fixed their code already because other compilers have been doing this optimization for ages" etc Given the fact our typing system does use C as a low level assembly language, I am worried. I hope that these worries are unjustified. Jan