Re: compiler bugs

torbenm@pc-003.diku.dk (Torben Fgidius Mogensen) writes:


> Sid Touati <SidTouati@inria.fr> writes:
>
>> How can a simple programmer detect a bug in a compiler ? is there some
>> well known verification techniques ?
...
> 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.


I would like to amplify this point. At some level, compilers aren't
that different from other programs written by other programmers. So,
think of the kind of bugs you experience.


            1) most bugs occur in new code


                  sometimes the new code stresses old code, but there is an
                  exponential decay in the numbers of bugs founds per block of
                  code over time and you can compute things like half-lives to
                  guess at the number of unfound bugs. (Most compiler code is
                  also "old", so the number of remaining bugs is diminishing.)


            2) most bugs actually cause spectacular failures (or are off-
                  by-ones); very few bugs give you subtly wrong output


                  How often do you write code and msake a small error (say
                  multiplying by 7 when you mean 8, or xor'ing when you mean to
                  and) that affects everything, but only by a little and is
                  subtle? It is more likely, you write errors where you
                  sometimes go 1 place to far or short in a loop or you forget
                  to initialize something, or you depend on something else
                  about some other code which just isn't true. Compiler
                  writers make the same kinds of mistakes.


                  Thus, if you are to find a bug in the compiler, the most
                  likely effect is that the compiler will crash. If it doesn't
                  crash, the code for the common cases (+, -, *, araays, and so
                  forth) is probably correct. Even the code for most uncommon
                  cases have probably been explored by someone other than you,
                  unless you are using a new feature of a compiler.


            2) many of the subtle bugs come from using grey-areas, where the
                  semantics themselves are subtle and one gets them wrong.


                  For example, I've just been fixing some code of mine where I
                  was filling up 64 bit structures (on a 32 bit machine) using
                  bit shifts--the bugs weren't in the compiler, the bugs were
                  in my using the wrong assumptions about the promotion rules.
                  People who mention aliasing problems are talking about a
                  similar effect. Now, these bugs would have been in this
                  compiler I'm writing, except that they showed up in my unit
                  testing, and I ensured that I went over all of the relevant
                  places and fixed them. Is it possible that I left a hole,
                  yes, but unlikely, and much more unlikely by the time that
                  even my initial customers see this compiler.


                  And, this brings up another point, most of the code I've
                  worked on in most compilers is pretty vanilla. Sure compiler
                  writer's are geeks and write some code that is too-clever,
                  but a lot of compiler code just uses arrays and pointer based
                  data structures (e.g. trees, dags) and integer and boolean
                  arithmetic. Thus, most the errors tend to be vanilla also.
                  We have pretty good techniques for catching and preventing
                  such errors. Most of the compiler code I write checks and
                  asserts each pointer access (or array bound). This tends to
                  increase the ratio of spectacular to hidden failures, but
                  helps me catch more bugs earlier.


And, yes, this list ended without a specific point.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)
-----------------------------------------------------------------------------

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