smart compilers

[Dick Dunn]

>  Dick Dunn <rcd at opus > writes:
>  > FORTRAN is so crippled in terms of
>  > being able to express what's "really going on" in its problem domain that
>  > a decent (let alone smart) compiler has to do a lot of optimization.
> 
>  Compilers that optimize code can break programs regardless of what 
>  language that code is written in.  Optimizing compilers are very useful
>  as long as the optimization is optional (or at least can be turned
>  off when the code involved may be sensitive to optimization).

Not quite fair to compilers.  If optimizing breaks programs which conform
to the language definition, the optimizer is broken.  If optimizing breaks
a program because the program is non-conforming (as, say, a program which
depends on order of evaluation in most languages), the program is at fault.
Using C assignments to manipulate or busy-wait on device registers is a
gray area, which is why (1) optimizers zing people on such code
periodically and (2) a mechanism like `volatile' has been proposed.

FORTRAN is less susceptible to clashes with the optimizer due to the
device-register sort of hassle but more susceptible to poor programming
such as parameter/COMMON aliasing, misunderstanding of modifying
initialized COMMON, etc.

(And yes, I know--the program is equally broken whether it's the
compiler's fault or the programmer's.)

As to turning off optimization--sometimes you want certain optimizations on
and others off, though this can be annoying for compiler-writers.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Are you making this up as you go along?