Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site uiucuxc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.UUCP
Newsgroups: net.bugs
Subject: Re: bug in some 68000 C-compilers
Message-ID: <10900007@uiucuxc.UUCP>
Date: Thu, 13-Sep-84 03:00:00 EDT
Article-I.D.: uiucuxc.10900007
Posted: Thu Sep 13 03:00:00 1984
Date-Received: Tue, 25-Sep-84 01:22:47 EDT
References: <228@digi-g.UUCP>
Lines: 13
Nf-ID: #R:digi-g:-22800:uiucuxc:10900007:000:636
Nf-From: uiucuxc!hamilton    Sep 13 02:00:00 1984

i reported this problem a while back (in net.micro, i think); it's effects
are even more widespread.  my UniSoft C compiler reuses one half of the
double result "register" as a scratchpad.  you'll see similar problems
with code like:
	double x[], atof();
	x[i] = atof(...);
the low-order fraction bits from the "atof" will get stomped by the
index calculation.  i "solved" my problem by avoiding "double"s
altogether.  i reported the problem to my micro vendor, who promised
to pass the word on to unisoft.  this was like last march... haven't
heard another word about it since.
	wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton