|[4 earlier articles]|
|Re: compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-28)|
|Re: compiler bugs email@example.com (Jeremy J Starcher) (2009-04-28)|
|Re: compiler bugs firstname.lastname@example.org (Louis Krupp) (2009-04-28)|
|Re: compiler bugs email@example.com (Jonathan Thornburg) (2009-04-28)|
|Re: compiler bugs firstname.lastname@example.org (2009-04-28)|
|Re: compiler bugs email@example.com (George Peter Staplin) (2009-04-28)|
|Re: compiler bugs firstname.lastname@example.org (Marco van de Voort) (2009-04-29)|
|Re: compiler bugs email@example.com (2009-04-29)|
|Re: compiler bugs firstname.lastname@example.org (Tony Finch) (2009-04-29)|
|Re: compiler bugs email@example.com (Derek M. Jones) (2009-04-29)|
|Re: compiler bugs firstname.lastname@example.org (glen herrmannsfeldt) (2009-04-29)|
|Re: compiler bugs email@example.com (Jeremy J Starcher) (2009-04-29)|
|Re: compiler bugs firstname.lastname@example.org (Walter Banks) (2009-04-30)|
|[12 later articles]|
|From:||Marco van de Voort <email@example.com>|
|Date:||Wed, 29 Apr 2009 08:45:34 +0000 (UTC)|
|Organization:||Stack Usenet News Service|
|Posted-Date:||29 Apr 2009 05:17:16 EDT|
On 2009-04-27, Sid Touati <SidTouati@inria.fr> 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.
Usually it is that way, program bugs are more numerous than compiler
bugs, if only because the compiler is vetted by a multitude of users.
It can be simply that turning on the optimization changes memory
layout that can causes hidden program bugs that mutilate memory
suddenly to become critical.
In general the best idea is to first do usual debugging stuff, like
using fencing heap allocators, turn on options that your compilers
might have (like randomized initialization of variables, range checks,
stack integrity cheching etc), as well as running in tools that can
detect certain classes of errors (like valgrind)
If that doesn't help, you can quickly inspect the assembler if you
have a feeling where the bug might be, and then (as the others already
advised) start narrowing down.
> 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...
It might be simply that the pointer bugs that surface without
optimization have been fixed during normal development. And the ones
WITH optimization only close to the release point, giving the
impression that the optimizer is very bugged.
Return to the
Search the comp.compilers archives again.