Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!emory!rsiatl!nanovx!techwood!paldn!pwilcox
From: pwilcox@paldn.UUCP (Peter McLeod Wilcox)
Newsgroups: comp.unix.i386
Subject: Re: Is this (gasp) a chip bug?
Summary: Microport SysV3.0 compiler's answer
Message-ID: <268@paldn.UUCP>
Date: 1 Aug 90 17:24:23 GMT
References: <1990Jul23.223341.26431@cbnewsc.att.com> <463@hitachi.uucp>
Sender: news@paldn.UUCP
Distribution: na
Organization: Paladin Solutions, Dawsonville GA
Lines: 39

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