Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!network.ucsd.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!caen!uunet!pipex!warwick!uknet!bradford.ac.uk!T.D.G.Sandford
From: T.D.G.Sandford@bradford.ac.uk (TDG SANDFORD)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] Bug in floating point
Message-ID: <1992Oct20.090304.13860@bradford.ac.uk>
Date: 20 Oct 92 09:03:04 GMT
References: <1992Oct19.175527.22365@netcom.com>
Organization: University of Bradford, UK
Lines: 33
Originator: 90908106@muser
Nntp-Posting-Host: muser
In article <1992Oct19.175527.22365@netcom.com> jtk@netcom.com (Jane Valencia) writes:
>While porting GNU Smalltalk, I ran across the following. I'm sure
>it's already found, but I couldn't prove it to myself by scanning
>old messages, so....
>
>GCC's treatment of an assignment "r = 0.0" to a double generates
>an assignment of -1 instead. "r = 0" works fine. I assume it's
>the floating point emulation (I have a 386 without 387) which
>is fooling GCC. Test program included below.
>
> Andy Valencia
>
>main()
>{
> double r;
>
> r = 0.0;
> printf("Result %lf\n", r);
> r = 0;
> printf("Result %lf\n", r);
> exit(0);
>}
I guess it must be the floating point emulation - I just compiled and ran
it on a 486 (so with fp hardware) with the following results:
% ./a.out
Result 0.000000
Result 0.000000
--
Thomas Sandford | t.d.g.sandford@bradford.ac.uk