Xref: utzoo comp.unix.ultrix:5150 comp.sys.sgi:6583 comp.sys.mips:1139
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!paperboy!meissner
From: meissner@osf.org (Michael Meissner)
Newsgroups: comp.unix.ultrix,comp.sys.sgi,comp.sys.mips
Subject: Re: Another C compiler bug
Message-ID: <MEISSNER.90Nov1151145@osf.osf.org>
Date: 1 Nov 90 20:11:45 GMT
References: <11565@sybase.sybase.com>
Sender: news@OSF.ORG
Organization: Open Software Foundation
Lines: 42
In-reply-to: mcfong@mercury.sybase.com's message of 31 Oct 90 21:46:42 GMT

In article <11565@sybase.sybase.com> mcfong@mercury.sybase.com writes:

| When the following program is run:
| 
| 	main()
| 	{
| 		printf("7e-7 = %f\n", 7e-7);
| 	}
| 
| I get the following results on the following MIPS-based systems:
| 
| 	RISC ULTRIX 3.0			7e-7 = 0.000000
| 	SGI IRIX 3.2			7e-7 = 0.000000
| 	MIPS OS 1.0			7e-7 = 0.000001
| 
| Looks like yet another compiler bug which MIPS has fixed but DEC and
| SGI have not yet picked up.
| 
| Would someone please run the same program on the latest version of RISC
| ULTRIX (4.0) and SGI IRIX (3.3) and see if DEC or SGI have fixed the
| problem in their later releases?

I did some checking (doesn't anybody look at the machine code these
days), and it's not a compiler bug, but a library bug.  You can
demonstrate it by changing the program to:

	main()
	{
		printf ("7e-7 = %g\n", 7e-7);
	}

and it will print "7e-7 = 7e-07" on my Ultrix 3.1 system.  On OSF/1,
it prints the correct answer.  I used by the standard C compiler (on
Ultrix) and GCC (on Ultrix and OSF/1), and they give identical
results.  I suspect the bug is that the library does not round %f
entries, but truncates them instead.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Do apple growers tell their kids money doesn't grow on bushes?