Is this (gasp) a chip bug?
Peter McLeod Wilcox
pwilcox at paldn.UUCP
Thu Aug 2 03:24:23 AEST 1990
The cc shipped with Microport SysV 386/3.0 has an amusing response to the
problem. It looked at the test ( "if ( (y-x) < 0 ) printf..." ) and decided
that the operation should be perform in unsigned math which would never
produce a negative value and thus unconditionally jumped around the true
clause. When the optimizer was turned on the code generated for:
main() {
unsigned long y = 0x7FFFF0FF;
unsigned long x = 0x7FFFF000;
while ( 1 ) {
if ( (y-x) < 0 ) ....
y++;
x++;
}
}
Reduced to:
main:
pushl %ebp
movl %esp,%ebp
subl $0x8,%esp
movl $0x7ffff00f,0xfc(%ebp)
movl $0x7ffff000,0xf8(%ebp)
loop:
incl 0xfc(%ebp)
incl 0xf8(%ebp)
jmp loop
This code, of course, generates the proper result (no result), but probably for
the wrong reasons. The problem seems to be one that would break many compilers
since the compiler is unable to promote the operands to signed integers. The
moral may be that arithmatic operations that can generate a negative value
may not be used on unsigned longs. It should be noted that such an operation
can generate a value impossible to represent, i.e. a negative number larger in
magnitude than 0x80000000 ( 1-0xffffff00 will break anything ).
--
Pete Wilcox ...gatech!nanovx!techwood!paldn!pwilcox
More information about the Comp.unix.i386
mailing list