Re: failure due to compiler?

resler@liberty.mas.vcu.edu (Dan Resler) writes:


>I am looking for pointers or references to descriptions where software
>has compiled without error and later failed due to compiler-introduced
>errors in the resultant program. In other words, the source was deemed
>to be error free but the compiler botched the code generation. Any
>help would be appreciated; thanks.


Borland C (for the x86) changed their code generation between v4.0 and
v4.5. It didn't affect C code... but they also allow frills like
inline assembly, and they have psuedo-names for all the processor regs
so you can access them directly. They have a demo program on the net
that combines some of this stuff together... worked fine under V4.0 of the
compiler but under 4.5 they had changed the internals significantly enough
to break their demo. Last I heard they were still insisting nothing was
wrong anywhere... but I had their demo and I had the assembly file the
compiler made and it definitely was not kosher. I've heard several
people complain about this demo, they always seem satisfied when I ship
them a fixed version.


Back when I was working with a standalone PASCAL that DEC made for
embedded work on the PDP-11, I was writing some pretty complex functions.
I found out during debugging that the optimizer on that particular compiler
had errors when you start doing complex expressions. It turned out the
best way to turn off the optimizer was to enable the debug mode... it didn't
try to do complex optimizations at that point so the debugger could keep
the source in sync with the generated code. It really bloated the code...
and probably slowed it down quite a bit... but at one point we turned that
optimizer off and then were never able to use it again.




I'm working on a C compiler... I've had all sorts of errors with the code
gen but I won't go into most of that because I was writing tests and
fixing them pretty rapidly. but once I was pretty confident with the compiler
I ran into two that really caused me headaches. The first one was
post-increment modes. They were actually implemented as pre-increment
modes. Really tricky to find... I had also implemented sparse
switch constructs as a sequence of compares arranged in a binary tree.
It passed all my tests but I found out today that it still doesn't work
right. Se la vie...




David
--

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