[MLton-devel] Fwd: Re: pretty damn good

[Brad Lucier]

> 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.

Brad


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel