compiler error in pcc found

utzoo!utcsrgv!utcstvax!geoff utzoo!utcsrgv!utcstvax!geoff
Fri Jul 30 06:48:06 AEST 1982


I seem to have found a bug in the pcc.  My pcc is on 4.1BSD.
Either of
	int umask = ((unsigned)~0)>>1;
	int umask = ((unsigned)4)>>1;
outside any function yields
"t.c", line 1: compiler error: expression causes compiler loop: try simplifying

The compiler spews out 32k bytes of code before collapsing:
	LL0:
		.data
		.align	2
		.globl	_umask
	_umask:
		movl	$1,r0
		movl	r0,-4(fp)
		movl	-4(fp),r0
		movl	r0,-8(fp)
		movl	-8(fp),r0
		movl	r0,-12(fp)
		movl	-12(fp),r0
	etc.
Pcc apparently believes umask to be a function, in spite of the ``=''
in the initialiser.  Inside a function, pcc generates (correct) code to
compute umask.  It seems that pcc doesn't think ((unsigned)~0)>>1 is a
constant.  Indeed, this line
	char chars[((unsigned)~0)>>10];
draws the complaint
	"t.c", line 1: constant expected
However,
	char chars[((int)~0)>>10];
draws
	"t.c", line 1: warning: zero or negative subscript
Presumably pcc understands that ((int)~0)>>10 is constant, so unsigned
must be the cause of the trouble.
	int umask = (((int)~0)>>1);
correctly initialises umask to -1.
	int umask = (unsigned)4;
	int umask = 4>>1;
both work correctly.

All of these test cases work correctly on the local Amdahl UTS system,
where right shifts never sign-extend.  I haven't tried the test cases
on the Ritchie compiler because our PWB system is down.

My motivation for all this is that (unsigned)~0>>1 is the largest integer
on a twos-complement machine.

Is anyone familiar with this problem? Anyone want to fix it?

Geoff Collyer, U. of Toronto Computing Services



More information about the Net.bugs mailing list