Xref: news2.mv.net comp.lang.c:56547 comp.lang.c++:72615 comp.os.msdos.djgpp:1126 gnu.g++.help:4635 gnu.gcc.help:5827
From: rfg AT monkeys DOT com (Ronald F. Guilmette)
Newsgroups: comp.lang.c,comp.lang.c++,gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp
Subject: Re: float != float and floats as return types
Date: 15 Feb 1996 01:20:39 -0800
Organization: Infinite Monkeys & Co.
Lines: 68
Message-ID: <4futt7$6b7@segfault.monkeys.com>
References: <4ej9lb$mpc AT fu-berlin DOT de> <4elnjj$er4 AT server2 DOT rz DOT uni-leipzig DOT de> <4eqc7l$ugh AT godzilla DOT zeta DOT org DOT au>
NNTP-Posting-Host: segfault.monkeys.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <4eqc7l$ugh AT godzilla DOT zeta DOT org DOT au>,
Bruce Evans <bde AT zeta DOT org DOT au> wrote:
>In article <4elnjj$er4 AT server2 DOT rz DOT uni-leipzig DOT de>,
>Steffen Winterfeldt <wfeldt AT physik DOT uni-leipzig DOT de> wrote:
>>Axel Thimm (axl AT zedat DOT fu-berlin DOT de) wrote:
>>: Hello,
>>: I am getting confused, about how C/C++ manage float binary operations,
>>: in particular multiplication. The next C++ example gives me surprising
>>: results:
>>: 	*** cut here: begin file t_prec.cc
>>: 	#include <iostream.h>
>>: 	#include <iomanip.h>
>>: 	#include <math.h>
>>: 	float quad( float );
>>: 	int main() {
>>: 	  for( int i=0; i<10; ++i ) {
>>: 	    float a, b, c;
>>: 	    a = i/13.123123;
>>: 	    b = a*a;
>>: 	    c = quad(a);
>>: 	    cout << (b - c) << '\t';
>>: 	    cout << (b - a*a) << '\t';
>>: 	    cout << (c - quad(a)) << '\n';
>>: 	  }
>>: 	  return 0;
>>: 	}
>>: 	float quad( float x ) { return x*x; }
>>: [...]
>>
>>(c - quad(a)) is not zero, because quad's return value is in a floating point
>>register and so has higher precision than c.
>
>Wrong.
>
>gcc's machine description for the i386 bogusly says that the result of a
>(float * float) calculation has float precision.  This is only true if
>the ambient precision is 24 bits or if -msoft-float is used.  Because of
>this, gcc omits the conversions that it would do if it had the correct
>precision (type) information.  It clips the extra precision for
>assignments from double variables or long double variables to float
>variables and for returning double or long double values from functions
>that return float, even if the value is originally in a floating point
>register and could end up in the same register.  The ANSI standard is
>ambiguous about whether these conversions must be done.

I agree that it is, however a response to an official Defect Report clearly
indicated that when a float is to be returned (as the result of a function)
and when the actual type of the expression appearing in a return statement
in that function is some wider floating-point type, then the result gets
narrowed ``as if passing through a knothole''.

> Anyway, gcc sometimes skips them...

This is a known bug in gcc/x86.

>If the ambient precision is 64 bits, as it is under Linux...

There is no such thing as an ``ambient precision''.

On x86 systems, it is generally easiest to carry out all FP operations using
80 bits (i.e. long double) and then narrow the results when required by the
standard.

-- 

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg AT monkeys DOT com ----------- Purveyors of Compiler Test Suites -
------ Copyright (c) 1996 by Ronald F. Guilmette; All rights reserved. -----