Re: compiler bugs

George Peter Staplin <>
Tue, 28 Apr 2009 20:11:56 -0600

          From comp.compilers

Related articles
[3 earlier articles]
compiler bugs (Sid Touati) (2009-04-27)
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)
[13 later articles]
| List of all articles for this month |

From: George Peter Staplin <>
Newsgroups: comp.compilers
Date: Tue, 28 Apr 2009 20:11:56 -0600
Organization: XMission
References: 09-04-072
Keywords: errors
Posted-Date: 29 Apr 2009 05:16:10 EDT

Sid Touati wrote:

> How can a simple programmer detect a bug in a compiler ? is there some
> well known verification techniques ?

Most assembly code that I know about is not proven correct by any sort
of formal method, or verification technique. There was a research
project that implemented a provably correct assembler, but the code I
looked at was quite strange, and the assembler itself was for an
architecture I don't use IIRC.

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

Yes, indeed that's a problem. In some ways rigorous testing may help,
and in other ways it may hinder future changes. You definitely need a
test suite anyway for your compiler to verify the correctness of the
code produced, but as you might expect with languages like assembly,
some things may work unexpectedly due to state not changing that you
didn't expect. If and when you have multiple CPUs to support the
complexity increases.

Consider for example that a register has a value due to a specific
instruction that came before another code pattern that depends on that
value, but didn't explicitly set that value. This kind of bug happens
too often. It may even pass in many cases a torture test.

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

I agree, and understand. That's why you need great test coverage. My
compilers have been rather simple for the most part, but the tests end
up almost being as large as the compiler itself, when I do it right.

I think in some ways having a more structured design with hypertext,
and multiple layers would help a great deal to express and structure
solutions for the complex problems we face, as NLS has proven. The
NLS system was implemented in the 1960's and they had good ideas. My
belief however about NLS is something that most people don't share in
the computing industry. I have been going forward in my spare time on
a project. My project is focusing on enabling hypertext, layers, and
code constraints applied in a visual way. In fact the constraints
have to be visual to work in any sort of sane and expressable manner.

NLS had MOL (machine-oriented language) as its base. NLS was a very
powerful and interesting system to me, and without it we might not
have the computer mouse. The system allowed managing complexity in
ways I don't think we can do in general now, without more indirection.


Post a followup to this message

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