Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [4 earlier articles] |
| Re: compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-28) |
| Re: compiler bugs r3jjs@yahoo.com (Jeremy J Starcher) (2009-04-28) |
| Re: compiler bugs lkrupp@indra.com (Louis Krupp) (2009-04-28) |
| Re: compiler bugs jonathan@nitrogen.astro.indiana.edu (Jonathan Thornburg) (2009-04-28) |
| Re: compiler bugs jgd@cix.compulink.co.uk (2009-04-28) |
| Re: compiler bugs georgeps@xmission.com (George Peter Staplin) (2009-04-28) |
| Re: compiler bugs marcov@stack.nl (Marco van de Voort) (2009-04-29) |
| Re: compiler bugs torbenm@pc-003.diku.dk (2009-04-29) |
| Re: compiler bugs dot@dotat.at (Tony Finch) (2009-04-29) |
| Re: compiler bugs derek@knosof.co.uk (Derek M. Jones) (2009-04-29) |
| Re: compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-04-29) |
| Re: compiler bugs r3jjs@yahoo.com (Jeremy J Starcher) (2009-04-29) |
| Re: compiler bugs walter@bytecraft.com (Walter Banks) (2009-04-30) |
| [12 later articles] |
| From: | Marco van de Voort <marcov@stack.nl> |
| 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 <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
comp.compilers page.
Search the
comp.compilers archives again.