Re: Strange g+ 3.1.1 double behavior

Re: Strange g+ 3.1.1 double behavior

[Michael Veksler]

References: <3D4E8656.6030402@informatik.uni-kl.de> <3D4E889D.243FAFCB@acm.org>



Gunther Weber wrote:

> Thank you for your answer. That explains how this problem occurs. 
> -float-store (-mfloat-store does not exist) does not help, but 
> |-mno-fp-ret-in-387 helps. Anyway, I will not use these options. Insted 
> I will get rid of my misconception that identical floating point 
> calculations yield identical results and |write my programs accordingly. 
> So thank you for explaining this to me as it may help to prevent future 
> grief that would have resulted from holding on to my misconception :-)


I think you were correct to assume that FP calculations should yield
identical results. This is true at least according to IEEE standard.
Some time ago I had a similar complaint:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6914

At the end of this page you can find a solution to your problem.
Also, it contains an explanation why I think current behavior is wrong
(the gcc/glibc combination does something wrong thing with FP arithmetic)

Re: Strange g+ 3.1.1 double behavior

[Gunther Weber]

Nathan Sidwell wrote:

>>    
>>
>Not necesarily. floating point calculations can be performed at a
>higher precision, and this happens on i86 hardware. IIRC the return value
>will be in an i86 floating point register at 80 bits precision. One
>return value must be stored on the stack (in a 64 bit double, hence
>rounded), the other return value need not be, so is not rounded. The
>result you see is the rounding error. This spilling of intermediates
>at a lower precision is a quality of implementation thing.
>
>-mfloat-store might help you here.
>
>nathan
>
>  
>
Thank you for your answer. That explains how this problem occurs. 
-float-store (-mfloat-store does not exist) does not help, but 
|-mno-fp-ret-in-387 helps. Anyway, I will not use these options. Insted 
I will get rid of my misconception that identical floating point 
calculations yield identical results and |write my programs accordingly. 
So thank you for explaining this to me as it may help to prevent future 
grief that would have resulted from holding on to my misconception :-)

Gunther

Re: Strange g+ 3.1.1 double behavior

[Nathan Sidwell]

Gunther Weber wrote:

> while searching for a problem in one of my programs I ran across this
> strange gcc 3.1.1 beahvior:

>   std::cout << torus(0.0,0.0,10.0) -  torus(0.0,0.0,10.0) << std::endl;

> 3.85469e-13


> All this on a Celeron system running RedHat 7.3. Does anyone what could
> be causing this?  I would expect that both function calls with identical
> arguments would result in the same double value and thus in the programm
Not necesarily. floating point calculations can be performed at a
higher precision, and this happens on i86 hardware. IIRC the return value
will be in an i86 floating point register at 80 bits precision. One
return value must be stored on the stack (in a 64 bit double, hence
rounded), the other return value need not be, so is not rounded. The
result you see is the rounding error. This spilling of intermediates
at a lower precision is a quality of implementation thing.

-mfloat-store might help you here.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
           The voices in my head told me to say this
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

Strange g+ 3.1.1 double behavior

[Gunther Weber]

Hello,

while searching for a problem in one of my programs I ran across this 
strange gcc 3.1.1 beahvior:

--- TestFloat.cc ---
#include <iostream>

double torus(double x, double y, double z)
{
  const double R = .7;
  const double r = .1;
  return (x*x + y*y)*(x*x + y*y) - 2*(R*R + (r*r - z*z))*(x*x + y*y) +
    (R*R - (r*r - z*z))*(R*R - (r*r - z*z));
}


int main()
{
  std::cout << torus(0.0,0.0,10.0) -  torus(0.0,0.0,10.0) << std::endl;
}
--- Test Float.cc ---

--- Log ---.
[weber@stella Test]$ g++3.1.1 TestFloat.cc 
-Wl,--rpath,/usr/global/packages/languages/gcc-3.1.1/lib
[weber@stella Test]$ ./a.out
3.85469e-13
[weber@stella Test]$ g++3.1.1 --version
g++3.1.1 (GCC) 3.1.1
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc3.1.1 -v
Reading specs from 
/usr/global/packages/languages/gcc-3.1.1/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/specs
Configured with: ./configure 
--prefix=/usr/global/packages/languages/gcc-3.1.1 --enable-languages=c,c++
Thread model: single
gcc version 3.1.1
[weber@stella Test]$ ldd a.out
        libstdc++.so.4 => 
/usr/global/packages/languages/gcc-3.1.1/lib/libstdc++.so.4 (0x40014000)
        libm.so.6 => /lib/i686/libm.so.6 (0x400d4000)
        libgcc_s.so.1 => 
/usr/global/packages/languages/gcc-3.1.1/lib/libgcc_s.so.1 (0x400f6000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
--- Log ---

All this on a Celeron system running RedHat 7.3. Does anyone what could 
be causing this?  I would expect that both function calls with identical 
arguments would result in the same double value and thus in the programm 
printing "0".

Thank you for any help
  Gunther H Weber