flee@shire.cs.psu.edu (Felix Lee) (02/09/89)
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.
If you compile with at least -O2 optimization, it works correctly.
--
Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
[[ Send it to Sun (if you haven't already)! They'll see it someday.
--wnl ]]aoki@sun.com (Chris Aoki) (02/16/89)
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.