|[24 earlier articles]|
|Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-20)|
|Re: failure due to compiler? email@example.com (Dara Gallagher) (1996-07-20)|
|Re: failure due to compiler? firstname.lastname@example.org (1996-07-22)|
|Re: failure due to compiler? email@example.com (1996-07-22)|
|Re: failure due to compiler? firstname.lastname@example.org (Lee Webber) (1996-07-23)|
|Re: failure due to compiler? email@example.com (Eric Hamilton) (1996-07-23)|
|Re: failure due to compiler? firstname.lastname@example.org (1996-07-23)|
|Re: failure due to compiler? email@example.com (1996-07-24)|
|Re: failure due to compiler? firstname.lastname@example.org (1996-07-26)|
|Re: failure due to compiler? email@example.com (1996-07-31)|
|Re: failure due to compiler? firstname.lastname@example.org (1996-07-31)|
|From:||email@example.com (Dave Gillett)|
|Date:||23 Jul 1996 23:37:31 -0400|
|References:||96-07-041 96-07-056 96-07-065|
> 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.
I've seen errors introduced during porting of code from one compiler to
language in subtle ways. That is, the correctness of the source depended upon
which compiler was used. [It was usually not hard to modify the source to
avoid the semantic ambiguity.]
I also once wrote some code in which an inlined C++ function called itself
recursively. The compiler generated two copies of the function code, a
top-line copy inline and an out-of-line copy to be called and to recurse.
Unfortunately, the two copies were not the same. The top-line copy's version
of its main "while" loop was incorrectly optimized (it re-used a register while
thinking it was preserved). The out-of-line code was correct -- until I
removed the "inline" designation so that the compiler only generated the
out-of-line instance of the code, which at that point exhibited the same error.
The fix was to recode the loop conditions to make them less obvious targets
for bogus optimization.
Return to the
Search the comp.compilers archives again.