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

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> "Christopher Glaeser" <cdg@nullstone.com> writes:
>>>Even a simple bug fix to a new release in a compiler
>>>can affect the behavior of C programs that have undefined behavior.
>>
>> Different releases are a different issue than turning optimization on,
>> although changing behaviour between releases is not desirable, either.
>
>What about portability to a completely different compiler on a
>completely different machine? Do you expect your program to behave
>the same?


No. Porting can uncover portability bugs. But turning on an
optimizer is different from porting a program. Many programmers avoid
porting programs to a different compiler or platform, or incur a large
amount of extra effort when they do. Do you think that they should
treat optimization the same way? Then they will avoid the optimizer
just like they avoid porting. Then the optimizer will just be a
benchmarketing exercise.


>I think you're attacking the wrong folks, here. If optimizers can
>affect the behavior of programs, that's primarily the fault of the
>language designer, not the compiler writer.


The language specifiers [1] do not force optimizers to break working
(albeit non-standard) programs; if the optimizer does that, the
optimizer writer is to blame, nobody else.


Yes, stronger language specifications are a good idea, because they
make porting easier. But that has little to do with optimization.


[1] Whether the specification comes from a designer or design group,
or as the result of a standardization effort.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

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