Re: compiler bugs

Sid Touati <SidTouati@inria.fr> writes:


> How can a simple programmer detect a bug in a compiler ? is there some
> well known verification techniques ?


There have been research projects about verifying the correctness of
compilers, but they have (to my knowledge) all been for fairly simple
compilers. You will, basically, have to build the compiler with
verification in mind to have any chance of doing this.


Another approach is to make a verifying compiler: One that checks the
correctness of each compiled program. This way, you don't prove that
the compiler is correct, but you catch "bad" programs.


These techniques are, however, sot for "simple programmers" (whatever
that means). Also, these techniques need formal specifications of
both the source language and the target machine. And it is often the
case that such formal specifications themselves have bugs, so you just
move the problem to a higher level of abstraction, unless you define
the language by it formal semantics.


> I am afraid that many bugs are hidden inside compiler activated with
> sophisticated optimisation options, and few people can detect them: when
> a user program does not work, we usually think that the problem comes
> from the program itself, not from the compiler nor from the processor.


And that is also the most likely case.


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


If you use floating point computations and the language definition is
not specific about evaluation order and precision, optimisation may
change the precision of your calculations which may cause subsequent
program behaviour to diverge (two values that test equal without
optimisation may test not equal afterwards, or vice-versa).


That said, compilers are very large and complex pieces of software and
incredibly difficult to test, since you can't normally validate the
correctness of the output -- the best you can do is to test the
output, so your tests are more indirect than if you test, say, a
sorting functin where you can fairly easily verify that the output is
a sorted permutation of the input.


So, it is not unlikely that there are errors in your compiler. The
unlikely part is that you will be the first to notice the errors. Not
only are compilers tested rather thoroughly, but if a compiler is in
wide usage, most bugs are bound to show up fairly quickly. It is
normally only when you program in a very unusual style or push the
limits of the language that you find new bugs.


If you are convinced that the problem is not in your program, you
should (as other posters have said) reduce your program to the
smallest possible that still shows the problem and only then report
the problem to the compiler vendor. If the vendor agrees that it is,
indeed, a bug in the compiler, they are likely to ask to add your
program to their test suite, so subsequent versions of the compiler
test for this problem.


Torben

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