Mail Archives: djgpp/1996/02/15/05:38:08
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. -----
- Raw text -