Re: failure due to compiler?

grout@polestar.csrd.uiuc.edu (John R. Grout)
18 Jul 1996 23:54:39 -0400

          From comp.compilers

Related articles
[13 earlier articles]
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)
Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-20)
Re: failure due to compiler? jgllgher@maths.tcd.ie (Dara Gallagher) (1996-07-20)
[9 later articles]
| List of all articles for this month |
From: grout@polestar.csrd.uiuc.edu (John R. Grout)
Newsgroups: comp.compilers
Date: 18 Jul 1996 23:54:39 -0400
Organization: Center for Supercomputing R and D, UIUC
References: 96-07-035
Keywords: errors

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.


Another rich source of bugs involves generating correct code for parallel
environments.


To simplify user coding, the IBM PL/S language provided an attribute for
data structures (or portions of data structures) requring the use of
explicit synchronization for updates (generating explicit AND/OR
Immediate instructions for such fields was wrong, because those
instructions did not serialize... instead, the compiler would synthesize
equivalent sequences of AND/OR Register and Compare (Double) and Swap
instructions).


However, even when a compiler team thinks they've generated the correct
synchronization code, sometimes it doesn't quite work... here's another
anecdote.


A certain research compiler was generating buggy parallel code for the
Cray Y-MP. After some work, the compiler group supporting it managed to
reproduce the bug for a very simple program much like this FORTRAN
equivalent:


j = 0
do i = 1,1000000
j = j + 1
enddo
print *, j
c Sometimes the program did not output 1 million


After some more tedious debugging, they found out that the Cray Y-MP
memory consistency model was very complicated... not only did they have
to get exclusive control of a shared memory location _before_ updating
it, they also had to issue a synchronization instruction _after_ updating
it to make sure that the write was visible in the correct order to other
processors (much as one would have to in the Alpha architecture... in
practice, one would use Alpha's horizontal microcode primitives to do
such things, not naked instructions as the Cray Y-MP requires).


--
John R. Grout Center for Supercomputing R & D j-grout@uiuc.edu
Coordinated Science Laboratory University of Illinois at Urbana-Champaign
--


Post a followup to this message

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