Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
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;
}
This looks insane. Am I misreading it, or does it really say that
`*(&t.i)' is different than `t.i'? Also, why should union type
variables be any different than other variables in this regard? For
instance:
int f() {
int a;
int *ip;
a = 10;
ip = &a;
return *ip;
}
How is this any different than what is done above?
"everybody has fixed their code already because other compilers
have
been doing this optimization for ages"
If the last is really the case, then we indeed have nothing to worry
about. XEmacs has compiled and run on non-Gcc compilers for ages.
*If* the last is really the case.