Xref: utzoo comp.bugs.4bsd:789 comp.lang.c:9438 comp.unix.wizards:7842
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!trantor.umd.edu!chris
From: chris@trantor.umd.edu (Chris Torek)
Newsgroups: comp.bugs.4bsd,comp.lang.c,comp.unix.wizards
Subject: Re: Why the 4.3BSD C compiler seem to botch this ?
Message-ID: <2570@umd5.umd.edu>
Date: 18 Apr 88 04:12:03 GMT
References: <153@rna.UUCP>
Sender: ris@umd5.umd.edu
Reply-To: chris@trantor.umd.edu (Chris Torek)
Organization: University of Maryland, College Park
Lines: 28

In article <153@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes:
>	The code below seems okay and does passed thru SUN's C compiler fine,
>but the 4.3BSD C compiler misgenerates a label, causing an assembler error
>messages and an unknown external (during loading).

As you might guess, it is a bug in the compiler, or more precisely, a
bug in the optimiser, which goofs `tst' instructions that are not
followed by a branch.  Specifically:

>	register unsigned i, j, k;
[stuff deleted]
>			for (j = i - k; (j >= 0) && (a[j] > w); j -= k)

The test `j >= 0' is always true, so the compiler generates

	tstl	rJ	# is it < 0?
	cmpd	...	# no!, so do the other half of the && expression

Removing the `j >= 0' test from the source stops the optimiser from
botching its job, although the code is wrong either way.  Replacing
the loop with

	for (j = i - k; (int)j >= 0 && a[j] > w; j -= k)

also does the trick, and incidentally fixes the sort; alternatively,
declare j as `int' rather than `unsigned'.
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
Domain: chris@mimsy.umd.edu		Path: ...!uunet!mimsy!chris