Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!think!nike!ll-xn!adelie!axiom!linus!philabs!mcnc!ece-csc!mark
From: mark@ece-csc.UUCP (Mark Lanzo)
Newsgroups: net.micro.amiga
Subject: Re: LATTICE BUG (3.03)		-unsigned? short optimization bug
Message-ID: <3111@ece-csc.UUCP>
Date: Wed, 8-Oct-86 14:12:18 EDT
Article-I.D.: ece-csc.3111
Posted: Wed Oct  8 14:12:18 1986
Date-Received: Sat, 11-Oct-86 21:08:47 EDT
References: <8610020736.AA09001@cory.Berkeley.EDU>
Reply-To: mark@ece-csc.UUCP (Mark Lanzo)
Organization: North Carolina State University, Raleigh, NC
Lines: 49

In article <8610020736.AA09001@cory.Berkeley.EDU>
 dillon@CORY (Matt Dillon) writes:
==>
==>	Here is an obscure lattice bug.   V3.03 (no suffix)  I'm
==>	probably the only one who has run into it.
==>
==>
==>CODE:
==>
==>main()
==>{
==>   unsigned short x, xx;
==>   unsigned short y = 0xFFFF;
==>   unsigned short z = 2;
==>
==>   x = (y + z) / 16;
==>   xx= ((y + z) / 16);
==>   printf ("x = %ld %ld\n", x, xx);
==>}
==>
==>
==>EXPECTED RESULT: (remember, y and z are supposed to be expanded to ints first)
==>
==>   4096 4096

Actually, I wonder about this.  Shouldn't the expected result be zero?

The partial sum (y+z) should be done completely in ushort, giving
      0xFFFF + 0x0002  = 0x0001 (retaining only the lower 16 bits)

so that the quotient (1/16) [done in integer math] should be zero.
I don't see any reason why the code generated for "x=..." and "xx=..."
should differ.

Am I missing something here?

==>
==>ACTUAL RESULT:
==>
==>   1 1

Of course, by my reasoning, the actual result is also wrong, which would
still indicate that you were correct about a compiler bug.


If I've said something blatantly stupid here, please don't flame
too hard :-)

   --- Mark ---