C compiler bug (I think).

[chris at umcp-cs.UUCP]

It's obviously a compiler bug.  More interesting is the code that
comes out of the (4.2BSD) compiler:

	% /lib/ccom
	int one = (unsigned) 2 >> 1;
[compiler output]
		.data
		.align	2
		.globl	_one
	_one:
		movl	$1,r0
		movl	r0,-4(fp)
		movl	-4(fp),r0
		movl	r0,-8(fp)
		movl	-8(fp),r0
		.
		.
		.

It only happens with the typecasts; ``int one = 2 >> 1;'' works.
``int one = (char) 2 >> 1;'' generates a similar endless stream, but
it begins differently:

		.data
		.align	2
		.globl	_one
	_one:
		movl	$2,r0
		movl	r0,-4(fp)
		mnegl	$1,r0
		movl	r0,-8(fp)
		movl	-8(fp),r0
		movl	r0,-12(fp)
		.
		.
		.

Obviously what's happening is this: during expression tree
optimization, the compiler is trying to compute the value at RUNtime.
However, as there are no free registers, it keeps sticking values into
r0, finding out it can't get another free register, pushing r0 for
safekeeping, getting the next number into r0, finding out it doesn't
have a free register for the ``ashl'' operation, . . . .  Things work
if the operation is done inside {}s because there are some registers
free.

The bug is probably simply that the compiler is missing optimizations
for expressions involving types other than `int' (and `long') for the
">>" and "<<" operators when both LHS and RHS are integer constants.
(Both << and >> generate the endless stream of junk).

(I wonder why the register allocation code doesn't scream loudly when
asked for registers while code generation is off?)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland