Re: compiler bugs

Marco van de Voort <>
Wed, 29 Apr 2009 08:45:34 +0000 (UTC)

          From comp.compilers

Related articles
[4 earlier articles]
Re: compiler bugs (Hans-Peter Diettrich) (2009-04-28)
Re: compiler bugs (Jeremy J Starcher) (2009-04-28)
Re: compiler bugs (Louis Krupp) (2009-04-28)
Re: compiler bugs (Jonathan Thornburg) (2009-04-28)
Re: compiler bugs (2009-04-28)
Re: compiler bugs (George Peter Staplin) (2009-04-28)
Re: compiler bugs (Marco van de Voort) (2009-04-29)
Re: compiler bugs (2009-04-29)
Re: compiler bugs (Tony Finch) (2009-04-29)
Re: compiler bugs (Derek M. Jones) (2009-04-29)
Re: compiler bugs (glen herrmannsfeldt) (2009-04-29)
Re: compiler bugs (Jeremy J Starcher) (2009-04-29)
Re: compiler bugs (Walter Banks) (2009-04-30)
[12 later articles]
| List of all articles for this month |

From: Marco van de Voort <>
Newsgroups: comp.compilers
Date: Wed, 29 Apr 2009 08:45:34 +0000 (UTC)
Organization: Stack Usenet News Service
References: 09-04-072
Keywords: errors
Posted-Date: 29 Apr 2009 05:17:16 EDT

On 2009-04-27, 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.

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.

Post a followup to this message

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