Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: aoki@sun.com (Chris Aoki)
Newsgroups: comp.sys.sun
Subject: Re: Sun4 C compiler generates bad code under strange conditions
Message-ID: <8902100639.AA01705@sisyphus.sun.com>
Date: 15 Feb 89 16:19:12 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 32
Approved: Sun-Spots@rice.edu
Original-Date: Thu, 9 Feb 89 22:39:15 PST
X-Sun-Spots-Digest: Volume 7, Issue 156, message 1 of 11

Felix Lee <flee@shire.cs.psu.edu>:
>Compile and run the following (on a Sun4/260, SunOS4.0):
>
>	main() { printf("%d %d\n", x(0), x(1)); }
>	x(a) int a; { return (a==0) ? 99 : y() + y(); }
>	y() { return 12; }
>
>Curiously enough, it prints 0 and 12, instead of 99 and 24.  Looking at
>the assembly code, the compiler is putting the intermediate return value
>of x() into %i5, instead of somewhere useful, like %o0.

Ancient PCC bug, which occurs more readily on machines with more freely
available registers like SPARC.  From our SCCS history:

1.1	static char *sccsid ="@(#)reader.c	1.1 (Berkeley) 9/7/82";
1.1	# include "mfile2"
1.1	
	....
1.1		/* if any rewriting and canonicalization has put
1.1		 * the tree (p) into a shape that cook is happy
1.1		 * with (exclusive of FOREFF, FORREW, and INTEMP)
1.1		 * then we are done.
1.1		 * this allows us to call order with shapes in
1.1		 * addition to cookies and stop short if possible.
1.1		 */
1.1		if( tshape(p, cook &(~(FOREFF|FORREW|INTEMP))) )return;

This bit of cleverness causes the code generator to stop short if the
expression has been evaluated into a register, even though the author
clearly forgot to check whether the register is the right one.

Fixed in 4.1, or possibly in a bug fix release before then.