Re: compiler bugs

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.


-George

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