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

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.