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

Pertti Kellomaki <pertti.kellomaki@tut.fi> writes:


> Anton Ertl wrote:
>> * Do you analyse the program to see if it is actually
>> standard-conformant? If it isn't, do you consider the program to be
>> incorrect, the optimizer to be correct, and do you mark the bug
>> report as invalid? Then you are an apologist. If you don't write
>> optimizers, but think that this attitude is ok, then you are also an
>> apologist.
>
> Or a formalist. For example, the Scheme specification does not specify
> the order in which function arguments are evaluated. As far as I am
> concerned, an implementation would be free to evaluate arguments left
> to right on weekdays and right to left on weekends. If my code relies
> on something that is not explicitly promised by the language, that's
> my fault, not the compiler's.


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


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.


Torben
[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]

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