Re: compiler bugs

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Fri, 01 May 2009 10:31:27 GMT

          From comp.compilers

Related articles
[12 earlier articles]
Re: compiler bugs dot@dotat.at (Tony Finch) (2009-04-29)
Re: compiler bugs derek@knosof.co.uk (Derek M. Jones) (2009-04-29)
Re: compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-04-29)
Re: compiler bugs r3jjs@yahoo.com (Jeremy J Starcher) (2009-04-29)
Re: compiler bugs walter@bytecraft.com (Walter Banks) (2009-04-30)
Re: compiler bugs cfc@shell01.TheWorld.com (Chris F Clark) (2009-04-30)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-01)
Re: compiler bugs gene.ressler@gmail.com (Gene) (2009-05-01)
Re: compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-04)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-05)
Re: compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-05)
Re: compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-05)
Re: compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-06)
[29 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Fri, 01 May 2009 10:31:27 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 09-04-072 09-04-086
Keywords: errors
Posted-Date: 01 May 2009 19:22:40 EDT

torbenm@pc-003.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen) writes:
>Sid Touati <SidTouati@inria.fr> writes:
>> On the other hand, when a compilation flag is on and the program
>> crashes, we usually think that the bug comes from the compiler not from
>> the program...
>
>Even if your program changes behaviour when you turn on optimisation
>flags, this may not imply faults in the compiler, just that the
>language has a weak specification that leaves, say, the order of
>evaluating function arguments up to the compiler. The non-optimising
>compiler may just evaluate in order, while an optimising compiler may
>rearrange the order for better scheduling or such. If some of the
>arguments have side effects, this can change program behaviour.


An optimizer that breaks a program is a bad idea. There are
apologists (of program-breaking optimizers) that claim that the
program was already broken without the optimizer, because it does not
conform to some language standard. But actually the program does
conform with the language as it is implemented by the compiler without
optimization and it behaves as intended by the programmer, so it is
correct.


That the program does not conform to some other language specification
should be irrelevant to the optimizer, because the optimizer should
preserve the behaviour of the non-optimizing compiler. Ok, in some
cases this costs a little (e.g., to preserve the order of potential
side effects in the example above), and in some cases it's not
practically possible and would buy very little (e.g., preserving the
exact values of return addresses so an out-of-bounds array read may
get the same value), but in general that's how optimizer writers
should approach the issue.


Otherwise we will soon be back to the bad old days when everybody just
considered turning on the optimizer too risky because it tends to
break programs; and the rhetoric of the apologists won't help, because
at least for languages like C most (all?) substantial programs don't
conform to the language standard, and there is no cost-effective way
to turn such programs into standard-conforming programs. So if the
optimizer feels free to break such programs, programmers just will
not use the optimizer.


If an optimizer writer also wants to excel on benchmarks by weakening
the semantic guarantees to the lowest common denominator (i.e., the
language standard plus the stuff used in the benchmarks), they can add
special flags for that, say, -Ospec.


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


Post a followup to this message

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