Re: behavior-preserving optimization in C, was compiler bugs

> I agree. But I also think that it is a problem for a language to
> leave visible behaviour unspecified, except for indirectly visible
> behaviour such as resource use. So, you should only leave order of
> evaluation unspecified if the order can not directly influence the
> result of the program, i.e., when there are no side effects.


Agreed so far.


  > This does not mean that the language shold be free of side effects,
> but only that the language definition guarantees that side-effecting
> computations are in the same standardized order regardless of which
> compiler, optimisation level or target machine you use.


Alternatively (e.g., Fortran), the standard requires (only) that set
of computations to be free of such side-effects as might make the
result indeterministic.


> Why rely on the programmer to ensure that his code is independent of
> evaluation order? A compiler can usually do this more reliably than
> an average programmer.


While I agree, this is unfortunately academic - most people, and in
particular that subset raised on C/C++ - seem to be unable to accept
(or sometimes even grasp) the concept of the compiler being their
"nanny".


And technically, it isn't easy to do. Even a very restrictive language
such as occam2 made it impossible to use, in a practical program, the
alias and usage checker because of its implementation
deficencies. Yes, that implementation could have been improved, in
particular in its handling of arrays and array slices, and
Fortran-like slice notation would have made its life easier as
well...but doing this without getting in the way of legitmate cases is
very hard. Perhaps the Ada way (be strict in the compiler, but accept
the programmer's explicit instructions to not perform a check here or
there) is the right way to go.


> [The traditional Fortran answer is that the more latitude you give
> the compiler, the faster code it can generate. I agree this makes
> it harder to write reliable code since you have to defend against
> all the transformations it might do. -John]


See above. I don't think it makes it really that much harder...in
fact, given the pitfalls that are present in other languages that you
can avoid in this way, the bottom line is very likely that your coding
is faster and easier.


Jan
[The particular Fortran problem is that the standard allows the compiler
to make rearrangements that are mathematically equivalent but not
floating point computationally equivalent. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.