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