geoff (07/30/82)
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