Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| failure due to compiler? resler@liberty.mas.vcu.edu (1996-07-03) |
| Re: failure due to compiler? kanze@lts.sel.alcatel.de (1996-07-04) |
| Re: failure due to compiler? gclind01@starbase.spd.louisville.edu (1996-07-07) |
| Re: failure due to compiler? ian@five-d.com (1996-07-07) |
| failure due to compiler? flake@elda.demon.co.uk (1996-07-09) |
| Re: failure due to compiler? dennis@netcom.com (1996-07-10) |
| Re: failure due to compiler? dennis@netcom.com (1996-07-10) |
| Re: failure due to compiler? grout@polestar.csrd.uiuc.edu (1996-07-10) |
| Re: failure due to compiler? khays@sequent.com (1996-07-10) |
| Re: failure due to compiler? cliffc@ami.sps.mot.com (1996-07-10) |
| Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-13) |
| [28 later articles] |
| From: | flake@elda.demon.co.uk (Peter L Flake) |
| Newsgroups: | comp.compilers |
| Date: | 9 Jul 1996 13:22:29 -0400 |
| Organization: | Elda Technology Ltd |
| References: | 96-07-041 |
| Keywords: | errors |
|> 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.
The most obscure compiler bug I ever came across was in the Multics BCPL
compiler. It had a code generation bug which depended on which procedure was
done first. It also had a random number generator based on the CPU clock which
determined the order in which code generation was done. So a correct BCPL
program would sometimes compile correctly, and sometimes incorrectly!
--
Peter L Flake Elda Technology Ltd.
27 Langley Drive, Camberley, Surrey, UK.
Tel/Fax +44 1276 20488
[Anyone got any insight into why in the world they made a non-deterministic
compiler? -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.