[MLton-devel] Fwd: Re: pretty damn good
Tue, 5 Nov 2002 09:21:23 -0500 (EST)
> Isn't the requirement for -fno-strict-aliasing a clear indication of a bug in
> gcc's -O2 optimization? A bit scary.
(I will not take the bait, I will not take the bait, ... Ah, what the hell.)
No, it means that there's a bug in MLton's C back end. Or, more precisely,
that MLton generates C code that violates the memory aliasing requirements
of C90, requirements on which gcc normally relies to optimize code with -O2.
The aliasing rules of C90 are roughly as follows:
1. If a hunk of memory is accessed by dereferencing a char* or void*
pointer, then gcc must assume that it could be accessed by
dereferencing any other type of pointer, too.
2. Otherwise, gcc can assume that the memory will be accessed by
dereferencing only a single type of pointer. So, e.g., it can
assume that memory accessed by dereferencing an int* is disjoint
from memory accessed by dereferencing a double*. And, in fact, it
acts on these assumptions.
By using union types one can state the usual relationships one requires for
a Scheme or ML back end in a way that doesn't violate the aliasing rules.
Or one can just give the -fno-strict-aliasing flag to gcc.
-fno-strict-aliasing was the default through gcc 3.0.
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
MLton-devel mailing list