Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!hal!mark
From: mark@mips.COM (Mark G. Johnson)
Newsgroups: comp.sys.sgi
Subject: Re: C compiler bug?   Answer: No.
Message-ID: <40162@mips.mips.COM>
Date: 15 Jul 90 16:37:31 GMT
References: <9007131953.AA08463@prism> <40159@mips.mips.COM> <11073@medusa.cs.purdue.edu>
Sender: news@mips.COM
Lines: 36

The problem is this: the source code assumes it will be run on a
little-endian machine.  Presumably the Sequent incorporates an
Intel CPU, which is little-endian.  The SGI (as well as the Sun,
MIPS, and Apollo machines mentioned earlier) are all big-endian.

Further evidence comes from the DECstation 3100, a little-endian
machine which uses the same CPU (R2000) and same C compiler as the SGI.
However, the DS3100 gets the answer that John Forrest wants, CRC=9cda,
while the SGI does not.

You can monkey around in the debugger to see this, or you can insert
the following printf statement in between two existing assignments:
------------------------------------------------------------------------------
------------------------------------------------------------------------------
       temp = (iUn.Bit.i7 ^ iUn.Bit.i6 ^ iUn.Bit.i5 ^
               iUn.Bit.i4 ^ iUn.Bit.i3 ^ iUn.Bit.i2 ^
               iUn.Bit.i1);

printf("DEBUG:  iUn.i = %3d    LSBs 4 3 2 1 = %d %d %d %d    temp = %d\n",
(iUn.i), (iUn.Bit.i4), (iUn.Bit.i3), (iUn.Bit.i2), (iUn.Bit.i1), temp );

       EntryUn.EntryBit.b16 = (iUn.Bit.i8 ^ temp);
------------------------------------------------------------------------------
------------------------------------------------------------------------------

On the SGI you find that "the LSBs" are all zeroes, while on the DS3100
they contain ones as appropriate.



In short, this "bug" seems to be a problem with the source code, not the
C compiler.
-- 
 -- Mark Johnson	
 	MIPS Computer Systems, 930 E. Arques M/S 2-02, Sunnyvale, CA 94086
	(408) 524-8308    mark@mips.com  {or ...!decwrl!mips!mark}