> From: Bob Miller [mailto:kbob@jogger-egg.com]
> Bill Tutt wrote:
> > Casts are indeed nasty things, and casts to (void *) are especially
nasty,
> > especially if you want SVN to compile safely under
> > -fstrict-aliasing in gcc.
> >
> > See http://gcc.gnu.org/onlinedocs/gcc_2.html#SEC11 and the commentary on
> > -fstrict-aliasing.
> I've read it, but I don't understand. Under what machine architectures
> or runtime models would the pointer break as its type changes?
> The example from the gcc page was:
> union a_union {
> int i;
> double d;
> };
> int f() {
> a_union t;
> int* ip;
> t.d = 3.0;
> ip = &t.i;
> return *ip;
> }
The optimization that turns on when -fstrict-aliasing is set isn't specific
to any architecture, or runtime model.
Optimizing compiler backfill:
Optimizing compilers (esp. for C and C++) generally need to be very paranoid
about areas of memory that are pointed to by more than place.
Example:
A compiler builtin version of memmove() could emit more optimal code
for a particular invocation if it could prove that the passed in parameters
never alias (overlap) the same memory.
The option -fstrict-aliasing allows GCC to assume the aliasing rules
specified by the C and C++ standards actually hold.
This allows the compiler to find more optimization opportunities. The
example on the gcc page of something that might not work is an undefined
ANSI C fragment with regard to optimizing based on ANSI C aliasing rules.
When code violates these rules, the optimizer may end up generating bad
code. Unfortunately, it's not very easy to
Not being a language lawyer, I'm not even going to try writing down what the
aliasing rules are in a short paragraph. :)
The basic idea is that you should always deal with memory with whatever it's
"real" data type is.
You can dig up some more info on the issue by searching through the gcc
mailing lists at: http://gcc.gnu.org/ml/gcc/
Aliasing would be a decent search word.
Bill
Received on Sat Oct 21 14:36:11 2006