|Possible to write compiler to Java VM? (I volunteer to summarize) email@example.com (Peter Seibel) (1996-01-17)|
|Re: Aliasing in ISO C firstname.lastname@example.org (1996-02-14)|
|Re: Aliasing in ISO C email@example.com (1996-02-16)|
|Re: Aliasing in ISO C firstname.lastname@example.org (1996-02-16)|
|Re: Aliasing in ISO C email@example.com (1996-02-16)|
|Re: Aliasing in ISO C firstname.lastname@example.org (1996-02-17)|
|Re: Aliasing in ISO C email@example.com (1996-02-19)|
|Re: Aliasing in ISO C Joris.Welkenhuysen@ping.be (1996-02-24)|
|From:||firstname.lastname@example.org (David L Moore)|
|Date:||17 Feb 1996 22:48:40 -0500|
|References:||<email@example.com 96-02-171 96-02-187|
> More than once I have heard it said that "I wouldn't dare" use this or
> that bit of small print for this or that optimization. The logic is
> clear: programs will fail mysteriously because the average programmer
> cannot be counted on to have read (and remembered) all the fine print.
The most interesting "optimization" of this kind is "optimization from
non-conformance". Some standards contain language which says that a
program that does so-and-so is non-conforming and that the results are
undefined. In other words, the compiler is free to do whatever it
likes with such code. Well, one option is to throw the code away!
So, for example, if a call to a Fortran function has aliased
parameters, one could simply decide to not call the function! I doubt
many customers could be convinced of the soundness of such an
I had an interesting case where an Ada compiler I was working on
failed to pass one member of the validation suite with optimization
on. However, the optimization, which involved optimizing away an
expression which would have raised an exception, was perfectly valid
under the old standard. As the new standard requires the exception to
be raised, it is reasonable to suggest that the bug was not in the
optimizer, nor in the test suite, but in the standard.
Return to the
Search the comp.compilers archives again.