Mail Archives: djgpp-workers/1999/07/22/00:27:28
Incidentally, one of the big changes with gcc 2.95 is that the ANSI
aliasing rules are now strictly enforced by default. The relevant docs
section follows:
----------------------------------------------------
-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;
}
Every language that wishes to perform language-specific alias
analysis should define a function that computes, given an tree node, an
alias
set for the node. Nodes in different alias sets are not allowed to
alias. For an example, see the C front-end function c_get_alias_set.
-------------------------------------------------
Linux, for example, is having some troubles with this, since the kernel
is full of such code, and currently GCC will handle it by generating the
"wrong" code but not issuing warnings. Before gcc 2.95 comes into wide
use, it might be wise to audit libc for suspicious code and fix it. Or
else, arrange to compile it with -fno-strict-aliasing.
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -