Re: c++/6914: -O2 and -O give different results for the same valid FP code

Re: c++/6914: -O2 and -O give different results for the same valid FP code

[Michael Veksler]

The following reply was made to PR c++/6914; it has been noted by GNATS.

From: "Michael Veksler" <VEKSLER@il.ibm.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: tprince@computer.org, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org
Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code
Date: Tue, 4 Jun 2002 09:48:07 +0300

 Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote:
 > At 17:49 03.06.2002, Michael Veksler wrote:
 > >If the decision will be to keep the current behavior, documentation
 > > should be updated. It should be more clear that -float-store is
 > > critical for IEEE
 > > conformance on targets like x86. Also, the bugs section should
 > > contain this as a known bug (and bug it is -- gcc does not
 > > conform to the IEEE standard on x86).
 >
 > Because GCC does not mess with the settings of the CPU, which is
 > certainly _not_ GCC's job. Checkout glibc's documentation and look
 > at stuff like fpu_control.h and fenv.h.
 
 I totaly agree that it is not GCC's job to fiddle with the settings of the 
 CPU.
 fpu_control.h took me by surprise (especially the _FPU_EXTENDED vs.
 _FPU_DOUBLE macros).
 
 Do you think this is a glibc bug?
 In "fpu_control.h" (at least 2.2-9) it is written:
 /* The fdlibm code requires strict IEEE double precision arithmetic,
    and no interrupts for exceptions, rounding to nearest.  */
 
 And then they go on and define
 #define _FPU_DEFAULT  0x037f
 
 Which effectively sets rounding to _FPU_EXTENDED (=0x300), instead of 
 double.
 This does seem like a glibc bug (documentation does not match reality).
 
 
 But, there are several open issues:
 1. This should be more clearly stated in the documentation of GCC.
    - In the bugs section (or non-bugs, actually).
      Recommend to use either -float-store, or the following code:
 #include <fpu_control.h>
 void set_rounding_to_double()
 {
 fpu_control_t fpu_bits;
 _FPU_GETCW(fpu_bits);
 fpu_bits &= ~_FPU_EXTENDED;
 fpu_bits |= _FPU_DOUBLE;
 _FPU_SETCW(fpu_bits);
 }
    - In gcc --help (on -float-store)
 2. The _FPU_* macros are not documented in the "man" pages, nor in the 
 info 
     (the only reference to them is in g77.info)
 
 I still get the feeling that GCC douesthe wrong thing here. Are there no
 opcodes for "divide and round to double", and for "compare as double" ?
 I think that GCC should minimize its dependency on the "correctness" of
 CPU settings. This of course, only if that does not change code size, and
 does not hurt performance.
 
 

Re: c++/6914: -O2 and -O give different results for the same valid FP code

[Franz Sirl]

The following reply was made to PR c++/6914; it has been noted by GNATS.

From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: "Michael Veksler" <VEKSLER@il.ibm.com>
Cc: tprince@computer.org,gcc-gnats@gcc.gnu.org,gcc-prs@gcc.gnu.org,
 gcc-bugs@gcc.gnu.org
Subject: Re: c++/6914: -O2 and -O give different results for the same
  valid FP code
Date: Mon, 03 Jun 2002 18:16:21 +0200

 At 17:49 03.06.2002, Michael Veksler wrote:
 >Tim Prince wrote:
 >+ Among the remedies available would be
 >+ a) set 53-bit rounding mode
 >+ b) choose -msse2, for appropriate targets
 >
 >After rereading the gcc manual, I found "-ffloat-store" which is the best 
 >remedy. It is described in:
 >http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Optimize-Options.html#Optimize%20Options
 >
 >It says "For most programs, the excess precision does only good". This 
 >statement is wrong. It is unbearable to have a perfectly valid
 >code behave differently with -O2 and -O0 on the same platform. The default
 >should be changed to -ffloat-store. Of course, when passing 
 >-funsafe-math-optimizations, gcc may also set -fno-float-store.
 >
 >If the decision will be to keep the current behavior, documentation should
 >be updated. It should be more clear that -float-store is critical for IEEE
 >conformance on targets like x86. Also, the bugs section should contain
 >this as a known bug (and bug it is -- gcc does not conform to the IEEE
 >standard on x86).
 
 Because GCC does not mess with the settings of the CPU, which is certainly 
 _not_ GCC's job. Checkout glibc's documentation and look at stuff like 
 fpu_control.h and fenv.h.
 
 Franz.
 

Re: c++/6914: -O2 and -O give different results for the same valid FP code

[Michael Veksler]

The following reply was made to PR c++/6914; it has been noted by GNATS.

From: "Michael Veksler" <VEKSLER@il.ibm.com>
To: tprince@computer.org
Cc: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code
Date: Mon, 3 Jun 2002 18:49:24 +0300

 Tim Prince wrote:
 + Among the remedies available would be
 + a) set 53-bit rounding mode
 + b) choose -msse2, for appropriate targets
 
 After rereading the gcc manual, I found "-ffloat-store" which is the best remedy. It is described in:
 http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Optimize-Options.html#Optimize%20Options
 
 It says "For most programs, the excess precision does only good". This statement is wrong. It is unbearable to have a perfectly valid 
 code behave differently with -O2 and -O0 on the same platform. The default 
 should be changed to -ffloat-store. Of course, when passing -funsafe-math-optimizations, gcc may also set -fno-float-store.
 
 If the decision will be to keep the current behavior, documentation should 
 be updated. It should be more clear that -float-store is critical for IEEE 
 conformance on targets like x86. Also, the bugs section should contain 
 this as a known bug (and bug it is -- gcc does not conform to the IEEE 
 standard on x86).
 

Re: c++/6914: -O2 and -O give different results for the same valid FP code

[Tim Prince]

The following reply was made to PR c++/6914; it has been noted by GNATS.

From: Tim Prince <tprince@computer.org>
To: veksler@il.ibm.com, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code
Date: Mon, 3 Jun 2002 06:30:53 -0700

 On Monday 03 June 2002 06:09, Michael Veksler wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&
 >pr=6914
 >
 > So here are my conclusions (after reading the assembly, and running gdb
 > on it):
 > Floating point on x86 is done on 80 bit registers (IEEE's double
 > extended type).
 > GCC generates code to exploit all 80 bits during divide. It then spills
 > the result
 > to memory.
 >
 > The second divide is not spilled to memory, and the comparison is done
 > between truncated value (which lost accuracy), and a completely accurate
 > 80 bit
 > value.
 > According to http://www.validlab.com/goldberg/paper.ps this does not
 > seem right.
 > According to this paper, gcc should operate on double precision (64
 > bit), or at
 > least give the impression that it does so (to the outside viewer). But
 > gcc operates
 > on a mixed 80/64 bit setting, and that seems contradictory to IEEE spirit
 > (and, probably, agains ISO C rules).
 >
 Among the remedies available would be 
 a) set 53-bit rounding mode
 b) choose -msse2, for appropriate targets
 
 -- 
 Tim Prince

Re: c++/6914: -O2 and -O give different results for the same valid FP code

[Michael Veksler]

The following reply was made to PR c++/6914; it has been noted by GNATS.

From: Michael Veksler <veksler@il.ibm.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, veksler@il.ibm.com,
   gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: c++/6914: -O2 and -O give different results for the same valid
 FP code
Date: Mon, 03 Jun 2002 16:09:30 +0300

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6914
 
 So here are my conclusions (after reading the assembly, and running gdb 
 on it):
 Floating point on x86 is done on 80 bit registers (IEEE's double 
 extended type).
 GCC generates code to exploit all 80 bits during divide. It then spills 
 the result
 to memory.
 
 The second divide is not spilled to memory, and the comparison is done
 between truncated value (which lost accuracy), and a completely accurate 
 80 bit
 value.
 According to http://www.validlab.com/goldberg/paper.ps this does not 
 seem right.
 According to this paper, gcc should operate on double precision (64 
 bit), or at
 least give the impression that it does so (to the outside viewer). But 
 gcc operates
 on a mixed 80/64 bit setting, and that seems contradictory to IEEE spirit
 (and, probably, agains ISO C rules).
 
 You can read the section about optimization.
 
 

Re: c++/6914: -O2 and -O give different results for the same valid FP code

[Michael Veksler]

The following reply was made to PR c++/6914; it has been noted by GNATS.

From: Michael Veksler <veksler@il.ibm.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, veksler@il.ibm.com,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/6914: -O2 and -O give different results for the same valid
 FP code
Date: Mon, 03 Jun 2002 14:47:32 +0300

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6914
 
 I managed to simplify this example, to a trivial C code.
 Please change category to C
 
 -------------- simplified example ----------
 double f();
 
 int main()
 {
     double a = 1.0 / f();
     double b = 1.0 / f();
 
     if(a < b)
          return 1;
 
     return 0;
 }
 
 double f() { return 3; }
 ----------- end example ----------
 
 The exit status of the resulting executable should be 0, but when compiled
 with -O2 it is 1.