Sun4 C compiler generates bad code under strange conditions

[Chris Aoki]

Felix Lee <flee at 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.