public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/6914: -O2 and -O give different results for the same valid FP code
@ 2002-06-03 4:46 Michael Veksler
0 siblings, 0 replies; 6+ messages in thread
From: Michael Veksler @ 2002-06-03 4:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c++/6914: -O2 and -O give different results for the same valid FP code
@ 2002-06-03 23:56 Michael Veksler
0 siblings, 0 replies; 6+ messages in thread
From: Michael Veksler @ 2002-06-03 23:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c++/6914: -O2 and -O give different results for the same valid FP code
@ 2002-06-03 9:26 Franz Sirl
0 siblings, 0 replies; 6+ messages in thread
From: Franz Sirl @ 2002-06-03 9:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c++/6914: -O2 and -O give different results for the same valid FP code
@ 2002-06-03 8:56 Michael Veksler
0 siblings, 0 replies; 6+ messages in thread
From: Michael Veksler @ 2002-06-03 8:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c++/6914: -O2 and -O give different results for the same valid FP code
@ 2002-06-03 6:36 Tim Prince
0 siblings, 0 replies; 6+ messages in thread
From: Tim Prince @ 2002-06-03 6:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c++/6914: -O2 and -O give different results for the same valid FP code
@ 2002-06-03 6:16 Michael Veksler
0 siblings, 0 replies; 6+ messages in thread
From: Michael Veksler @ 2002-06-03 6:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-06-04 6:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-03 4:46 c++/6914: -O2 and -O give different results for the same valid FP code Michael Veksler
2002-06-03 6:16 Michael Veksler
2002-06-03 6:36 Tim Prince
2002-06-03 8:56 Michael Veksler
2002-06-03 9:26 Franz Sirl
2002-06-03 23:56 Michael Veksler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).