Re: failure due to compiler?

glew@ichips.intel.com (Andy Glew)
16 Jul 1996 08:17:06 -0400

          From comp.compilers

Related articles
[11 earlier articles]
Re: failure due to compiler? jfc@mit.edu (1996-07-13)
Re: failure due to compiler? bobduff@world.std.com (1996-07-13)
Re: failure due to compiler? baynes@ukpsshp1.serigate.philips.nl (1996-07-13)
Re: failure due to compiler? alain@phidani.be (Corchia Alain) (1996-07-15)
Re: failure due to compiler? dave_sc@csl.sri.com (1996-07-15)
Re: failure due to compiler? kanze@lts.sel.alcatel.de (1996-07-16)
Re: failure due to compiler? glew@ichips.intel.com (1996-07-16)
Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-16)
Re: failure due to compiler? grout@polestar.csrd.uiuc.edu (1996-07-18)
Re: failure due to compiler? gah@u.washington.edu (1996-07-19)
Re: failure due to compiler? ok@cs.rmit.edu.au (1996-07-20)
Re: failure due to compiler? LEEW@FS.MICROLOGIC.COM (Lee Webber) (1996-07-20)
Re: failure due to compiler? iwm@doc.ic.ac.uk (Ian Moor) (1996-07-20)
[11 later articles]
| List of all articles for this month |

From: glew@ichips.intel.com (Andy Glew)
Newsgroups: comp.compilers
Date: 16 Jul 1996 08:17:06 -0400
Organization: Intel Corporation
References: 96-07-041 96-07-064
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.


Some old x86 compilers took


      if( b << c )


and generated:


    move bx, b
    move cl, c
    shift bx, cl
    jne ...


Problem: if the shift count c were 0 then the shift was defined to be
a NOP - *NOT* modifying the flags.


Unless the compiler can prove that c != 0, then the code emmitted must
be:


    move bx, b
    move cl, c
    shift bx, cl
    tst bx,bx ; compare to 0
    jne ...


This bug bit me in a simulator compiled with aforementioned compiler.


---


More apocryphally, I remember spending many days looking for bugs in
my NAPLPS kiosk database code, that turned out to be compiler bugs.
Don't have them now, of course.


---


On a more particular situation that is painfully close to home, does
anyone remember that Intel accidentally quoted SPECint95 numbers for
the P6, ah, Pentium Pro processor, that were about 10% too high? Yes,
it was really and truly due to a compiler bug in code generation for
EQNTOTT.
        Does being embarassed, and having to redo and republish benchmark
results, count as a failure?
---
Andy "Krazy" Glew, glew@ichips.intel.com, Intel,
M/S JF3-206, 2111 NE 25th Ave., Hillsboro, OR 97124
Place URGENT in email subject line for mail filter prioritization.
--


Post a followup to this message

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