|Re: Compiler bugs Peter-Lawrence.Montgomery@cwi.nl (2002-01-05)|
|Re: Compiler bugs firstname.lastname@example.org (Christian Bau) (2002-01-05)|
|Re: Compiler bugs email@example.com (David Chase) (2002-01-14)|
|compiler bugs SidTouati@inria.fr (Sid Touati) (2009-04-27)|
|Re: compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-28)|
|Re: compiler bugs firstname.lastname@example.org (Jeremy J Starcher) (2009-04-28)|
|Re: compiler bugs email@example.com (Louis Krupp) (2009-04-28)|
|Re: compiler bugs firstname.lastname@example.org (Jonathan Thornburg) (2009-04-28)|
|Re: compiler bugs email@example.com (2009-04-28)|
|Re: compiler bugs firstname.lastname@example.org (George Peter Staplin) (2009-04-28)|
|Re: compiler bugs email@example.com (Marco van de Voort) (2009-04-29)|
|Re: compiler bugs firstname.lastname@example.org (2009-04-29)|
|Re: compiler bugs email@example.com (Tony Finch) (2009-04-29)|
|[16 later articles]|
|From:||Louis Krupp <firstname.lastname@example.org>|
|Date:||Tue, 28 Apr 2009 11:33:36 -0600|
|Posted-Date:||28 Apr 2009 14:51:36 EDT|
Sid Touati wrote:
> How can a simple programmer detect a bug in a compiler ? is there some
> well known verification techniques ?
> 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.
> 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...
Identifying compiler bugs is usually a lot of work. Start with a
program that fails somewhere in its thousands of lines of code, and
spend the next few hours removing pieces until you have a minimal
program that reproduces the problem (or at least a problem -- there
could be more than one). In the early 90's, I spent a few years as a
contractor porting C++ code from one buggy compiler to another, so I
saw a lot of these. In one case, a C compiler generated bad code when
the program used a pointer to a function that took a float argument.
A later version of the compiler would have worked, but the customer
was too cheap to upgrade. I think I spent about 12 straight hours on
You'll need to be able to read compiler-generated assembly code.
Ironically, you won't need to be an expert in the compiled language; I
used the Annotated Reference Manual a lot, but by the time I got a C++
file down to the 20 lines or so needed to demonstrate the problem, it
was pretty obvious that there was a bug.
It's all worth it when you can send a description of the problem and
some sample code to the vendor, and it gets fixed.
(This was all a *lot* more fun years ago when I worked on Burroughs
Large Systems and they shipped the source code and I could fix some of
these in the field and report the problem to Mission Viejo along with
my suggested patch.)
Return to the
Search the comp.compilers archives again.