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

[Michael Veksler]

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.