[Bug rtl-optimization/323] optimized code gives strange floating point results

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #77 from pinskia at gcc dot gnu dot org  2005-10-15 18:34 -------
*** Bug 24387 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neff dot kevin at mayo dot
                   |                            |edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #78 from pinskia at gcc dot gnu dot org  2005-10-21 20:24 -------
*** Bug 24479 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dyang at mathworks dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #79 from pinskia at gcc dot gnu dot org  2005-11-10 03:41 -------
*** Bug 7935 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sk2alexa at math dot
                   |                            |uwaterloo dot ca


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #80 from pinskia at gcc dot gnu dot org  2005-12-08 01:47 -------
*** Bug 25303 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl at lucon dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #81 from pinskia at gcc dot gnu dot org  2006-01-28 03:56 -------
*** Bug 26000 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pr2345 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #82 from pinskia at gcc dot gnu dot org  2006-06-28 18:49 -------
*** Bug 28191 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rozenman at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[aph at gcc dot gnu dot org]

------- Comment #83 from aph at gcc dot gnu dot org  2006-08-02 10:56 -------
*** Bug 16825 has been marked as a duplicate of this bug. ***


-- 

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #84 from pinskia at gcc dot gnu dot org  2006-10-25 22:05 -------
*** Bug 29597 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brad_atcheson at yahoo dot
                   |                            |ca


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #85 from pinskia at gcc dot gnu dot org  2006-12-18 20:16 -------
*** Bug 30255 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |whaley at cs dot utsa dot
                   |                            |edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #86 from pinskia at gcc dot gnu dot org  2006-12-18 22:04 -------
*** Bug 30255 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[bruno at clisp dot org]

------- Comment #87 from bruno at clisp dot org  2006-12-21 15:08 -------
The option -ffloat-store, recommended by Richard Henderson, has the effect of
decreasing the performance of floating-point operations for the entire
compilation unit. If you want a minimal fix that does not affect other
functions in the same compilation unit, you can use 'volatile double'
instead of 'double'. It's like a one-shot -ffloat-store. Example:

#include <stdio.h>

void test(double x, double y)
{
  const volatile double y2 = x + 1.0;
  if (y != y2) printf("error\n");
}

void main()
{
  const double x = .012;
  const double y = x + 1.0;

  test(x, y);
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[egon at heaven dot industries dot cz]

------- Comment #88 from egon at heaven dot industries dot cz  2007-01-18 16:29 -------
>   const volatile double y2 = x + 1.0;

I'd also favor this "selective" approach, because the instability is harmless
in most cases.  But it is dangerous sometimes, as mentioned in the binary
search or when sorting, where the faulty cmpfn() could turn the sort function
to infinite loop.

So, could you please advise a body of hypothetical

double discard_extended_precision(double a);

function (possibly some 387 FP insn?) that reliably truncates the argument to
64bit?  Would

inline double discard_extended_precision(volatile double a) { return a; }

do the trick?


-- 

egon at heaven dot industries dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egon at heaven dot
                   |                            |industries dot cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[brooks at gcc dot gnu dot org]

------- Comment #89 from brooks at gcc dot gnu dot org  2007-02-10 00:55 -------
*** Bug 30752 has been marked as a duplicate of this bug. ***


-- 

brooks at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brooks at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu dot org]

------- Comment #90 from rguenth at gcc dot gnu dot org  2007-03-01 16:43 -------
*** Bug 31008 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcczilla at achurch dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #91 from pinskia at gcc dot gnu dot org  2007-03-09 20:11 -------
*** Bug 31114 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |terry at chem dot gu dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[whaley at cs dot utsa dot edu]

------- Comment #92 from whaley at cs dot utsa dot edu  2007-03-09 20:22 -------
I'd like to welcome the newest members of the bug 323 community, where all x87
floating point errors in gcc come to die!  All floating point errors that use
the x87 are welcome, despite the fact that many of them are easily fixable, and
many are not!  We're all one happy family, making the egregious mistake of
wanting
accuracy out of the most accurate general purpose FPU on the market!

Cheers,
Clint


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #93 from pinskia at gcc dot gnu dot org  2007-03-09 22:45 -------
*** Bug 31114 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[bonzini at gnu dot org]

------- Comment #94 from bonzini at gnu dot org  2007-04-02 16:20 -------
I think that Uros' patch to add a -mpc switch for precision control would "fix"
this.

The real fix would be to automatically insert fldcw instructions before
float/double operations, in order to limit the precision of the operations. 
But I think that it would kill speed even more than -ffloat-store.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[guillaume dot melquiond at ens-lyon dot fr]

------- Comment #95 from guillaume dot melquiond at ens-lyon dot fr  2007-04-03 17:51 -------
> I think that Uros' patch to add a -mpc switch for precision control would
> "fix" this.
> The real fix would be to automatically insert fldcw instructions before
> float/double operations, in order to limit the precision of the operations.
> But I think that it would kill speed even more than -ffloat-store.

Unfortunately, it is not that simple. The -mpc switch and the fldcw
instructions control the size of the significant, but they don't control the
range of the exponent. So it will solve the issue with the first testcase of
this bug-report, but you could still build examples where two execution paths
that perform the same floating-point computations produce completely different
results.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[David dot Monniaux at ens dot fr]

------- Comment #96 from David dot Monniaux at ens dot fr  2007-04-20 21:19 -------
The following paper explains how this kind of behaviour occurs, why it is
"correct", why it is difficult to fix but how it can be partly fixed, and how
this breaks many testing and proving techniques:

http://hal.archives-ouvertes.fr/hal-00128124


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #97 from pinskia at gcc dot gnu dot org  2007-06-19 08:11 -------
*** Bug 32391 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sunjoong at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[sliwa at cft dot edu dot pl]

------- Comment #98 from sliwa at cft dot edu dot pl  2007-08-03 12:09 -------
*** Bug 32976 has been marked as a duplicate of this bug. ***


-- 

sliwa at cft dot edu dot pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sliwa at cft dot edu dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[macracan at yahoo dot com]

------- Comment #99 from macracan at yahoo dot com  2007-10-01 17:43 -------
*** Bug 33611 has been marked as a duplicate of this bug. ***


-- 

macracan at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macracan at yahoo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #100 from pinskia at gcc dot gnu dot org  2007-12-29 19:46 -------
*** Bug 34616 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ismail at pardus dot org dot
                   |                            |tr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #101 from pinskia at gcc dot gnu dot org  2008-01-24 04:51 -------
*** Bug 34951 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tterribe at xiph dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #102 from pinskia at gcc dot gnu dot org  2008-01-27 23:17 -------
*** Bug 34992 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roebel at ircam dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #103 from pinskia at gcc dot gnu dot org  2008-02-27 20:38 -------
*** Bug 35389 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ywei at qualcomm dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[ywei at qualcomm dot com]

------- Comment #104 from ywei at qualcomm dot com  2008-02-27 21:41 -------
Subject: RE:  optimized code gives strange floating point results

Not sure this is the same issues as 323. All three numbers, 8, 1 and 65,
should be able to represented in IEEE 754 floating-point format exactly
without any rounding or approximation. That is
 8 = 1* 2^3
  1 = 1* 2^0
  65  = (1 + 1/64) * 2^6


-----Original Message-----
From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org] 
Sent: Wednesday, February 27, 2008 12:39 PM
To: Wei, Yongbin
Subject: [Bug rtl-optimization/323] optimized code gives strange
floating point results



------- Comment #103 from pinskia at gcc dot gnu dot org  2008-02-27
20:38 -------
*** Bug 35389 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
------------------------------------------------------------------------
----
                 CC|                            |ywei at qualcomm dot
com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #105 from pinskia at gcc dot gnu dot org  2008-03-06 22:44 -------
*** Bug 35488 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |purnnam1 at naver dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu dot org]

------- Comment #106 from rguenth at gcc dot gnu dot org  2008-03-06 23:14 -------
*** Bug 35488 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #107 from pinskia at gcc dot gnu dot org  2008-03-06 23:58 -------
*** Bug 35489 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu dot org]

------- Comment #108 from rguenth at gcc dot gnu dot org  2008-03-14 17:30 -------
*** Bug 35585 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicos at maunakeatech dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pepalogik at seznam dot cz]

------- Comment #109 from pepalogik at seznam dot cz  2008-05-20 16:59 -------
I also encountered such problems and was going to report it as a bug in GCC...
But in the GCC bug (not) reporting guide, there is fortunately a link to this
page and here (comment #96) is a link to David Monniaux's paper about
floating-point computations. This explains it closely but it is maybe too long.
I have almost read it and hope I have understood it properly. So I'll give a
brief explanation (for those who don't know it yet) of the reasons of such a
strange behaviour. Then I'll assess where the bug actually is (in GCC or CPU).
Then I'll write the solution (!) and finally a few recommendations to the GCC
team.

EXPLANATION
The x87 FPU was originally designed in (or before) 1980. I think that's why it
is quite simple: it has only one unit for all FP data types. Of course, the
precision must be of the widest type, which is the 80-bit long double.
Consider you have a program, where all the FP variables are of the type double.
You perform some FP operations and one of them is e.g. 1e-300/1e300, which
results in 1e-600. Despite this value cannot be held by a "double", it is
stored in an 80-bit FPU register as the result. Consider you use the variable
"x" to hold that result. If the program has been compiled with optimization,
the value need not be stored in RAM. So, say, it is still in the register.
Consider you need x to be nonzero, so you perform the test x != 0. Since 1e-600
is not zero, the test yields true. While you perform some other computations,
the value is moved to RAM and converted to 0 because x is of type "double". Now
you want to use your certainly nonzero x... Hard luck :-(
Note that if the result doesn't have its corresponding variable and you perform
the test directly on an expression, the problem can come to light even without
optimization.
It could seem that performing all FP operations in extended precision can bring
benefits only. But it introduces a serious pitfall: moving a value may change
the value!!!

WHERE'S THE BUG
This is really not a GCC bug. The bug is actually in the x87 FPU because it
doesn't obey the IEEE standard.

SOLUTION
The x87 FPU is still present in contemporary processors (including AMD) due to
compatibility. I think most of PC software still uses it. But new processors
have also another FPU, called SSE, and this do obey the IEEE. GCC in 32-bit
mode compiles for x87 by default but it is able to compile for the SSE, too. So
the solution is to add these options to the compilation command:
-march=* -msse -mfpmath=sse
Yes, this definitely resolves the problem - but not for all processors. The *
can be one of the following: pentium3, pentium3m, pentium-m, pentium4,
pentium4m, prescott, nocona, athlon-4, athlon-xp, athlon-mp, k8, opteron,
athlon64, athlon-fx and c3-2 (I'm unsure about athlon and athlon-tbird). Beside
-msse, you can also add some of -mmmx, -msse2, -msse3 and -m3dnow, if the CPU
supports them (see GCC doc or CPU doc).
If you wish to compile for processors which don't have SSE, you have a few
possibilities:
(1) A very simple solution: Use long double everywhere. (But be careful when
transfering binary data in long double format between computers because this
format is not standardized and so the concrete bit representations vary between
different CPU architectures.)
(2) A partial but simple solution: Do comparisons on volatile variables only.
(3) A similar solution: Try to implement a "discard_extended_precision"
function suggested by Egon in comment #88.
(4) A complex solution: Before doing any mathematical operation or comparison,
put the operands into variables and put also the result to a variable (i.e.
don't use complex expressions). For example, instead of { c = 2*(a+b); } ,
write { double s = a+b; c = 2*s; } . I'm unsure about arrays but I think they
should be OK. When you have modified your code in this manner, then compile it
either without optimization or, when using optimization, use -ffloat-store. In
order to avoid double rounding (i.e. rounding twice), it is also good to
decrease the FPU precision by changing its control word in the beginning of
your program (see comment #60). Then you should also apply -frounding-math.
(5) A radical solution: Find a job/hobby where computers are not used at all.

RECOMMENDATIONS
I think this problem is really serious and general. Therefore, programmers
should be warned soon enough.
This recommendation should be addressed especially to authors of programming
coursebooks. But I think there could also be a paragraph about it in the GCC
documentation (I haven't read it wholly but it doesn't seem there's any warning
against x87). And, of course, there should be a warning in the bug reporting
guide (http://gcc.gnu.org/bugs.html). It's fine there's a link to this page
(Bug 323) but the example with (int)(a/b) is insufficient. It only demonstrates
that real numbers are often not represented exactly in the computer. It doesn't
demonstrate the x87 pitfall. Hence there should be an example such as the
initial code of this "GCC bug 323 report". Because when one sees the example
with (int)(a/b), he can say "It's trivial" and not click the link (as I did the
first time).

EPILOGUE
I hope my effort of writing this "comment #109" will be helpful for many
people.
If you want more info, read the David Monniaux's work or something else about
FPUs.
Thanks to David Monniaux.


-- 

pepalogik at seznam dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pepalogik at seznam dot cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pepalogik at seznam dot cz]

------- Comment #110 from pepalogik at seznam dot cz  2008-06-12 14:14 -------
I used an old version of GCC documentation so I omitted some new processors
with SSE: core2, k8-sse3, opteron-sse3, athlon64-sse3, amdfam10 and barcelona.
I think you can use -march=pentium3 for all Intel's CPUs (of course, starting
with P3). I'm unsure about AMD. (Maybe you know it better.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #111 from vincent at vinc17 dot org  2008-06-20 16:09 -------
(In reply to comment #109)
> WHERE'S THE BUG
> This is really not a GCC bug. The bug is actually in the x87 FPU because it
> doesn't obey the IEEE standard.

Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard,
which *allows* extended precision, and double precision is *available*. In
fact, one could say that GCC even obeys the IEEE standard (which doesn't define
bindings: the definition of "destination" page 4 of the IEEE754-1985 standard
is rather vague and lets the language to define it exactly), but it doesn't
obey the ISO C99 standard on some point.

Concerning the x87 FPU: One can say however that the x87 is a badly designed
because it is not possible to statically specify the precision. Nevertheless
the OS/language implementations should take care of this problem.

Note: the solution chosen by some OS'es (*BSD, MS-Windows...) is to configure
the processor to the IEEE double precision by default (thus "long double" is
also in double precision, but this is OK as far as the C language is concerned,
there's still a problem with "float", but in practice, nobody cares AFAIK).

> If you wish to compile for processors which don't have SSE, you have a few
> possibilities:
> (1) A very simple solution: Use long double everywhere.

This avoids the bug, but this is not possible for software that requires double
precision exactly, e.g. XML tools that use XPath. See other examples here:

  http://www.vinc17.org/research/extended.en.html

Also this makes maintenance of software more difficult because long double can
be much slower on some platforms, which support this type in software to
provide more precision (e.g. PowerPC Linux and Mac OS X implement a
double-double arithmetic, Solaris and HPUX implement quadruple precision).

> (But be careful when transfering binary data in long double format between
> computers because this format is not standardized and so the concrete bit
> representations vary between different CPU architectures.)

Well, this is not specific to long double anyway: there exist 3 possible
endianess for the double format (x86, PowerPC, ARM).

> (2) A partial but simple solution: Do comparisons on volatile variables only.

Yes (but this is also a problem concerning the maintenance of portable
programs).

> (4) A complex solution: [...]

Yes, this is the workaround I use in practice.

> RECOMMENDATIONS
> I think this problem is really serious and general. Therefore, programmers
> should be warned soon enough.

Yes, but note that this is not the only problem with compilers. See e.g.

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578

for a bug related to casts to long double on x86_64 and ia64. This one is now
tested by: http://www.vinc17.org/software/tst-ieee754.c (which has also tested
bug 323 for a long time).


-- 

vincent at vinc17 dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17 dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pepalogik at seznam dot cz]

------- Comment #112 from pepalogik at seznam dot cz  2008-06-21 22:38 -------
(In reply to comment #111)
> Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard,
> which *allows* extended precision, and double precision is *available*.

It's true that double *precision* is available on x87. But not the *IEEE-754
"double precision" type*. Beside the precision of mantissa, this includes also
the range of exponent. On the x87, it is possible to set the precision of
mantissa but not the range of exponent. That's why I believe it doesn't obey
the IEEE. (I haven't ever seen the IEEE-754 standard but I base on the work of
David Monniaux.)

> Note: the solution chosen by some OS'es (*BSD, MS-Windows...) is to configure
> the processor to the IEEE double precision by default (thus "long double" is
> also in double precision, but this is OK as far as the C language is concerned,
> there's still a problem with "float", but in practice, nobody cares AFAIK).

Do you mean that on Windows, long double has (by default) no more precision
than double? I don't think so (it's confirmed by my experience). According to
the paper of David Monniaux, only FreeBSD 4 sets double precision by default
(but I know almost nothing about BSD).

> > (1) A very simple solution: Use long double everywhere.
> This avoids the bug, but this is not possible for software that requires double
> precision exactly, e.g. XML tools that use XPath.

Yes, of course. I don't say this can be used everywhere.

> > (But be careful when transfering binary data in long double format between
> > computers because this format is not standardized and so the concrete bit
> > representations vary between different CPU architectures.)
> Well, this is not specific to long double anyway: there exist 3 possible
> endianess for the double format (x86, PowerPC, ARM).

OK but David Monniaux mentions portability issues just in the case of long
double, so the differences are probably more frequent in this case (maybe even
within the x86 architecture).

> Yes, but note that this is not the only problem with compilers. See e.g.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578

Thanks for info.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #113 from vincent at vinc17 dot org  2008-06-22 00:52 -------
(In reply to comment #112)
> It's true that double *precision* is available on x87. But not the *IEEE-754
> "double precision" type*.

It is available when storing a result to memory.

> Beside the precision of mantissa, this includes also the range of exponent.
> On the x87, it is possible to set the precision of mantissa but not the range
> of exponent.

The IEEE754-1985 allows this. Section 4.3: "Normally, a result is rounded to
the precision of its destination. However, some systems deliver results only to
double or extended destinations. On such a system the user, which may be a
high-level language compiler, shall be able to specify that a result be rounded
instead to single precision, though it may be stored in the double or extended
format with its wider exponent range. [...]"

> That's why I believe it doesn't obey the IEEE. (I haven't ever seen the
> IEEE-754 standard but I base on the work of David Monniaux.)

See above. Also beware of subtilities in the wording used by David Monniaux.
FYI, the IEEE754-1985 standard (with minor corrections) is available from the
following page:
  http://www.validlab.com/754R/
(look at the end). AFAIK, the IEEE754-1985 standard was designed from the x87
implementation, so it would have been very surprising that x87 didn't conform
to IEEE754-1985.

> Do you mean that on Windows, long double has (by default) no more precision
> than double? I don't think so (it's confirmed by my experience).

I don't remember my original reference, but here's a new one:
  http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx
In fact, this depends on the architecture. I quote: "x86. Intermediate
expressions are computed at the default 53-bit precision with an extended range
provided by a 16-bit exponent. When these 53:16 values are "spilled" to memory
(as can happen during a function call), the extended exponent range will be
narrowed to 11-bits. That is, spilled values are cast to the standard double
precision format with only an 11-bit exponent.
A user may switch to extended 64-bit precision for intermediate rounding by
altering the floating-point control word using _controlfp and by enabling FPU
environment access (see The fpenv_access Pragma). However, when extended
precision register-values are spilled to memory, the intermediate results will
still be rounded to double precision.
This particular semantic is subject to change."

Note that the behavior has changed in some version of Windows (it was using the
extended precision, then it switched to double precision for x86). Now, this
may also depend on the compiler.

> According to the paper of David Monniaux, only FreeBSD 4 sets double
> precision by default (but I know almost nothing about BSD).

I've noted that amongst the BSD's, NetBSD does this too (I don't remember if
I've tried or got it from some document, and this might also depend on the
NetBSD version and/or the processor).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pepalogik at seznam dot cz]

------- Comment #114 from pepalogik at seznam dot cz  2008-06-22 16:59 -------
(In reply to comment #113)
> It is available when storing a result to memory.

Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109). So you could say that the IEEE754 double precision type is
available even on a processor without any FPU because this can be emulated
using integers.
Moreover, if we assess things pedantically, the workaround (4) still doesn't
fully obey the IEEE single/double precision type(s), because there remains the
problem of double rounding of denormals.

> The IEEE754-1985 allows this. Section 4.3: "Normally, a result is rounded to
> the precision of its destination. However, some systems deliver results only to
> double or extended destinations. On such a system the user, which may be a
> high-level language compiler, shall be able to specify that a result be rounded
> instead to single precision, though it may be stored in the double or extended
> format with its wider exponent range. [...]"
> [...]
> AFAIK, the IEEE754-1985 standard was designed from the x87
> implementation, so it would have been very surprising that x87 didn't conform
> to IEEE754-1985.

So it seems I was wrong but the IEEE754-1985 standard is also quite "wrong".

> > Do you mean that on Windows, long double has (by default) no more precision
> > than double? I don't think so (it's confirmed by my experience).
> I don't remember my original reference, but here's a new one:
>   http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx
> In fact, this depends on the architecture. I quote: "x86. Intermediate
> expressions are computed at the default 53-bit precision with an extended range
> [...]"

I quote, too:
"Applies To
   Microsoft® Visual C++®"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pepalogik at seznam dot cz]

------- Comment #115 from pepalogik at seznam dot cz  2008-06-22 17:28 -------
That ® should be (R).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #116 from vincent at vinc17 dot org  2008-06-22 21:14 -------
(In reply to comment #114)
> Yes, but this requires quite a complicated workaround (solution (4) in my
> comment #109).

The problem is on the compiler side, which could store every result of a cast
or an assignment to memory (this is inefficient, but that's what you get with
the x87, and the ISO C language could be blamed too for *requiring* something
like that instead of being more flexible).

> So you could say that the IEEE754 double precision type is available even on
> a processor without any FPU because this can be emulated using integers.

Yes, but a conforming implementation would be the processor + a library, not
just the processor with its instruction set.

> Moreover, if we assess things pedantically, the workaround (4) still doesn't
> fully obey the IEEE single/double precision type(s), because there remains the
> problem of double rounding of denormals.

As I said, in this particular case (underflow/overflow), double rounding is
allowed by the IEEE standard. It may not be allowed by some languages (e.g.
XPath, and Java in some mode) for good or bad reasons, but this is another
problem.

> I quote, too:
> "Applies To
>    Microsoft® Visual C++®"

Now I assume that it follows the MS-Windows API (though nothing is certain with
Microsoft). And the other compilers under MS-Windows could (or should) do the
same thing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pepalogik at seznam dot cz]

------- Comment #117 from pepalogik at seznam dot cz  2008-06-24 20:12 -------
(In reply to comment #116)
> > Yes, but this requires quite a complicated workaround (solution (4) in my
> > comment #109).
> 
> The problem is on the compiler side, which could store every result of a cast
> or an assignment to memory (this is inefficient, but that's what you get with
> the x87, and the ISO C language could be blamed too for *requiring* something
> like that instead of being more flexible).
> 
> > So you could say that the IEEE754 double precision type is available even on
> > a processor without any FPU because this can be emulated using integers.
> 
> Yes, but a conforming implementation would be the processor + a library, not
> just the processor with its instruction set.
> 
> > Moreover, if we assess things pedantically, the workaround (4) still doesn't
> > fully obey the IEEE single/double precision type(s), because there remains the
> > problem of double rounding of denormals.
> 
> As I said, in this particular case (underflow/overflow), double rounding is
> allowed by the IEEE standard. It may not be allowed by some languages (e.g.
> XPath, and Java in some mode) for good or bad reasons, but this is another
> problem.

OK, thanks for explanation. I think now it's clear.

> > I quote, too:
> > "Applies To
> >    Microsoft® Visual C++®"
> 
> Now I assume that it follows the MS-Windows API (though nothing is certain with
> Microsoft). And the other compilers under MS-Windows could (or should) do the
> same thing.

By a lucky hit, I have found this in the GCC documentation:
"
-mpc32
-mpc64
-mpc80
Set 80387 floating-point precision to 32, 64 or 80 bits. When '-mpc32' is
specified,
the significands of results of floating-point operations are rounded to 24
bits (single precision); '-mpc64' rounds the the significands of results of
floatingpoint
operations to 53 bits (double precision) and '-mpc80' rounds the significands
of results of floating-point operations to 64 bits (extended double precision),
which is the default. When this option is used, floating-point operations
in higher precisions are not available to the programmer without setting the
FPU control word explicitly.
[...]"

So GCC sets extended precision by default. And it's easy to change it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #118 from vincent at vinc17 dot org  2008-06-24 20:45 -------
(In reply to comment #117)
> By a lucky hit, I have found this in the GCC documentation:
> "
> -mpc32
> -mpc64
> -mpc80

OK, this is new in gcc 4.3. I haven't tried, but if gcc just changes the
precision without changing the values of <float.h> macros to make them correct,
this is just a workaround (better than nothing, though). Also, this is a
problem for library code if it requires to have double precision instead of
extended precision, as these options won't probably be taken into account at
that point. (Unfortunately it's probably too late to have a clean ABI.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[mbrudka at filbico dot pl]

------- Comment #119 from mbrudka at filbico dot pl  2008-07-17 10:45 -------
Another example related with fp on x87?

EXPECTED RESULT:
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)

REAL RESULT:
5.313991e+33
5.313991e+33
0.000000e+00
0.000000e+00

CODE
#include <stdio.h>
int main( void )
{
  /* register */ double d1 = 1e50;
  /* register */ double d2 = -2.7438011834107752e+51;
  /* register */ double s = 0.036445789368634796;
  /* register */ double d3 = -d1/s;
  /* register */ double d4 = s*d2;
  /* register */ double d5 = s*d3;
  printf( "%e\n", d1 + s*d2);
  printf( "%e\n", d1 + s*d3);
  printf( "%e\n", d1 + d4);
  printf( "%e\n", d1 + d5);
  return 0;
}


-- 

mbrudka at filbico dot pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mbrudka at filbico dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #120 from vincent at vinc17 dot org  2008-07-17 12:41 -------
(In reply to comment #119)
> REAL RESULT:
> 5.313991e+33
> 5.313991e+33
> 0.000000e+00
> 0.000000e+00

Only without optimizations. But since the ISO C standard allows expressions to
be evaluated in a higher precision, there's no bug here (unless you show a
contradiction with the value of FLT_EVAL_METHOD, but the FP_CONTRACT pragma
should also be set to OFF -- though this currently has no effect on gcc).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[mbrudka at filbico dot pl]

------- Comment #121 from mbrudka at filbico dot pl  2008-07-17 12:51 -------
Thank you Vincent. I fact after commenting I realized that this is a plain
numerical error on the last digit of double in multiplication. I think that my
comment was rather irrelevant and I am the more ashamed the more I cannot
remove it from bugzilla :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #122 from pinskia at gcc dot gnu dot org  2008-09-06 18:01 -------
*** Bug 37390 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at ubuntu dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jsm28 at gcc dot gnu dot org]

------- Comment #123 from jsm28 at gcc dot gnu dot org  2008-11-04 13:25 -------
Subject: Bug 323

Author: jsm28
Date: Tue Nov  4 13:24:30 2008
New Revision: 141578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141578
Log:
        PR rtl-optimization/323
        * c-common.c (convert_and_check, c_common_truthvalue_conversion):
        Handle EXCESS_PRECISION_EXPR.
        * c-common.def (EXCESS_PRECISION_EXPR): New.
        * c-cppbuiltin.c (builtin_define_float_constants): Define
        constants with enough digits for long double.
        * c-lex.c (interpret_float): Interpret constant with excess
        precision where appropriate.
        * c-opts.c (c_common_post_options): Set
        flag_excess_precision_cmdline.
        * c-parser.c (c_parser_conditional_expression): Handle excess
        precision in condition.
        * c-typeck.c (c_fully_fold): Handle EXCESS_PRECISION_EXPR.
        (c_fully_fold_internal): Disallow EXCESS_PRECISION_EXPR.
        (convert_arguments): Handle arguments with excess precision.
        (build_unary_op): Move excess precision outside operation.
        (build_conditional_expr): Likewise.
        (build_compound_expr): Likewise.
        (build_c_cast): Do cast on operand of EXCESS_PRECISION_EXPR.
        (build_modify_expr): Handle excess precision in RHS.
        (convert_for_assignment): Handle excess precision in converted
        value.
        (digest_init, output_init_element, process_init_element): Handle
        excess precision in initializer.
        (c_finish_return): Handle excess precision in return value.
        (build_binary_op): Handle excess precision in operands and add
        excess precision as needed for operation.
        * common.opt (-fexcess-precision=): New option.
        * config/i386/i386.h (X87_ENABLE_ARITH, X87_ENABLE_FLOAT): New.
        * config/i386/i386.md (float<SSEMODEI24:mode><X87MODEF:mode>2):
        For standard excess precision, output explicit conversion to and
        truncation from XFmode.
        (*float<SSEMODEI24:mode><X87MODEF:mode>2_1,
        *float<SSEMODEI24:mode><X87MODEF:mode>2_i387_with_temp,
        *float<SSEMODEI24:mode><X87MODEF:mode>2_i387, two unnamed
        define_splits, floatdi<X87MODEF:mode>2_i387_with_xmm, two unnamed
        define_splits, *floatunssi<mode>2_1, two unnamed define_splits,
        floatunssi<mode>2, add<mode>3, sub<mode>3, mul<mode>3, divdf3,
        divsf3, *fop_<mode>_comm_i387, *fop_<mode>_1_i387,
        *fop_<MODEF:mode>_2_i387, *fop_<MODEF:mode>_3_i387,
        *fop_df_4_i387, *fop_df_5_i387, *fop_df_6_i387, two unnamed
        define_splits, sqrt<mode>2): Disable where appropriate for
        standard excess precision.
        * convert.c (convert_to_real): Do not shorten arithmetic to type
        for which excess precision would be used.
        * doc/invoke.texi (-fexcess-precision=): Document option.
        (-mfpmath=): Correct index entry.
        * flags.h (enum excess_precision, flag_excess_precision_cmdline,
        flag_excess_precision): New.
        * langhooks.c (lhd_post_options): Set
        flag_excess_precision_cmdline.
        * opts.c (common_handle_option): Handle -fexcess-precision=.
        * toplev.c (flag_excess_precision_cmdline, flag_excess_precision,
        init_excess_precision): New.
        (lang_dependent_init_target): Call init_excess_precision.
        * tree.c (excess_precision_type): New.
        * tree.h (excess_precision_type): Declare.

ada:
        * gcc-interface/misc.c (gnat_post_options): Set
        flag_excess_precision_cmdline.

fortran:
        * options.c (gfc_post_options): Set flag_excess_precision_cmdline.

java:
        * lang.c (java_post_options): Set flag_excess_precision_cmdline.

testsuite:
        * gcc.target/i386/excess-precision-1.c,
        gcc.target/i386/excess-precision-2.c,
        gcc.target/i386/excess-precision-3.c,
        gcc.target/i386/excess-precision-4.c,
        gcc.target/i386/excess-precision-5.c,
        gcc.target/i386/excess-precision-6.c: New tests.

Added:
    branches/c-4_5-branch/gcc/ada/ChangeLog.c45
    branches/c-4_5-branch/gcc/fortran/ChangeLog.c45
    branches/c-4_5-branch/gcc/java/ChangeLog.c45
    branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-1.c
    branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-2.c
    branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-3.c
    branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-4.c
    branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-5.c
    branches/c-4_5-branch/gcc/testsuite/gcc.target/i386/excess-precision-6.c
Modified:
    branches/c-4_5-branch/gcc/ChangeLog.c45
    branches/c-4_5-branch/gcc/ada/gcc-interface/misc.c
    branches/c-4_5-branch/gcc/c-common.c
    branches/c-4_5-branch/gcc/c-common.def
    branches/c-4_5-branch/gcc/c-cppbuiltin.c
    branches/c-4_5-branch/gcc/c-lex.c
    branches/c-4_5-branch/gcc/c-opts.c
    branches/c-4_5-branch/gcc/c-parser.c
    branches/c-4_5-branch/gcc/c-typeck.c
    branches/c-4_5-branch/gcc/common.opt
    branches/c-4_5-branch/gcc/config/i386/i386.h
    branches/c-4_5-branch/gcc/config/i386/i386.md
    branches/c-4_5-branch/gcc/convert.c
    branches/c-4_5-branch/gcc/doc/invoke.texi
    branches/c-4_5-branch/gcc/flags.h
    branches/c-4_5-branch/gcc/fortran/options.c
    branches/c-4_5-branch/gcc/java/lang.c
    branches/c-4_5-branch/gcc/langhooks.c
    branches/c-4_5-branch/gcc/opts.c
    branches/c-4_5-branch/gcc/testsuite/ChangeLog.c45
    branches/c-4_5-branch/gcc/toplev.c
    branches/c-4_5-branch/gcc/tree.c
    branches/c-4_5-branch/gcc/tree.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[David dot Monniaux at imag dot fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]



------- Comment #124 from David dot Monniaux at imag dot fr  2008-11-11 07:46 -------
Vincent Lefèvre is right: the issue is quite subtle. (I should mention that
Vincent is an expert in computer arithmetics, which I'm not.)

As he rightly points, conformance to IEEE-754 should be evaluated for a whole
software/hardware system - it is possible to have a IEEE-754 system entirely
implemented in software.

It seems like the C99 standard prohibits double rounding, and prohibits having
values depend on the vagaries of register spilling. Except that this
prohibition is explicit only in non-normative sections. "Language lawyers" have
sent me justifications that this prohibition is implied by various normative
prescriptions of the standard.

I think that in any case we should not spend too much energy trying to assign
blame (who conforms to the standard) but rather try to find solutions.

The short answer is that no compiler, be it gcc, will be modified so that
complex sequences of operations are used for floating-point operations in lieu
of directly using x87 instructions! At least for two reasons:
* x87 is now fading away (its use is deprecated on x86-64, it's not used by
default on Intel Macintosh...)
* Most people don't want to pay the performance hit.

In addition, I think there are more urgent things to fix in gcc's
floating-point system, such as support for #pragma STDC FENV ACCESS

Now for some additional facts:
* It is possible to force the x87 to use reduced precision for the mantissa
(with inline asm or even now with gcc options).
* This setting does not affect the range of exponents. so you can still have
surprises if a very tiny nonzero value is kept in a register then is rounded to
zero when spilled to memory.
* In some rare cases, you can have "double rounding on underflow": you get a
different result by computing on SSE in double precision mode on the one hand,
and by computing on x87 in "double precision" then writing to a double variable
in memory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #125 from vincent at vinc17 dot org  2008-11-11 10:13 -------
(In reply to comment #124)
> It seems like the C99 standard prohibits double rounding,

only if Annex F is claimed to be supported (note: Annex F is not just IEEE 754,
it also contains specific bindings). IEEE 754 doesn't prohibit double rounding
either (this depends on the bindings), but with C99 + Annex F, double rounding
is prohibited.

Now, bug 323 is not about double rounding specifically. There are two potential
problems:

1. A "double" variable (or result of a cast) contains a "long double" value
(not exactly representable in a "double"). This is prohibited by C99
(5.1.2.3#12, 6.3.1.5#2 and 6.3.1.8#2[52]). This problem seems to be fixed by
Joseph Myers' patch mentioned in comment #123 (but I haven't tried).

2. Computations on "double" expressions are carried out in extended precision.
This is allowed by C99 (except for casts and assignments), e.g. when
FLT_EVAL_METHOD=2. But if the implementation (i.e. here compiler + library +
...) claims to support Annex F, then this is prohibited. This point is rather
tricky because the compiler (GCC) and library (e.g. GNU libc) settings must be
consistent, so their developers need to talk with each other. FYI, I reported
the following bug concerning glibc:

  http://sourceware.org/bugzilla/show_bug.cgi?id=6981

because it sets __STDC_IEC_559__ to 1 unconditionally.

> The short answer is that no compiler, be it gcc, will be modified so that
> complex sequences of operations are used for floating-point operations in lieu
> of directly using x87 instructions! At least for two reasons:
> * x87 is now fading away (its use is deprecated on x86-64, it's not used by
> default on Intel Macintosh...)
> * Most people don't want to pay the performance hit.

That's why in Joseph's patch, it's just an option (disabled by default, but
enabled by -std=c99 because one should assume that if a user wants C99, then he
really wants it, and if he is able to add an option, then he is also able to
add another one if he wants to disable this fix in case he knows it is useless
for his application -- this is also true for -ffast-math).

GCC already supports SSE, but this patch is for processors that don't.

Also the performance hit depends very much on the application. Performance hit
is reduced in applications that do not use intensive FP or mostly interactive
applications.

> In addition, I think there are more urgent things to fix in gcc's
> floating-point system, such as support for #pragma STDC FENV ACCESS

FYI, this is bug 34678. And I submitted bug 37845 concerning the FP_CONTRACT
pragma.

> * It is possible to force the x87 to use reduced precision for the mantissa
> (with inline asm or even now with gcc options).

Unfortunately, this means that "long double" wouldn't behave as expected, and
the behavior is not controllable enough (e.g. due to libraries, plugins...).
Such a change should have been system-wide. Now, this is needed in software
where double rounding is prohibited (e.g. XSLT processor).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jsm28 at gcc dot gnu dot org]

------- Comment #126 from jsm28 at gcc dot gnu dot org  2009-03-30 01:51 -------
Subject: Bug 323

Author: jsm28
Date: Mon Mar 30 01:50:44 2009
New Revision: 145272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145272
Log:
        PR rtl-optimization/323
        * c-common.c (c_fully_fold, convert_and_check,
        c_common_truthvalue_conversion): Handle EXCESS_PRECISION_EXPR.
        (c_fully_fold_internal): Disallow EXCESS_PRECISION_EXPR.
        * c-common.def (EXCESS_PRECISION_EXPR): New.
        * c-cppbuiltin.c (builtin_define_float_constants): Define
        constants with enough digits for long double.
        * c-lex.c (interpret_float): Interpret constant with excess
        precision where appropriate.
        * c-opts.c (c_common_post_options): Set
        flag_excess_precision_cmdline.  Give an error for
        -fexcess-precision=standard for C++ for processors where the
        option is significant.
        * c-parser.c (c_parser_conditional_expression): Handle excess
        precision in condition.
        * c-typeck.c (convert_arguments): Handle arguments with excess
        precision.
        (build_unary_op): Move excess precision outside operation.
        (build_conditional_expr): Likewise.
        (build_compound_expr): Likewise.
        (build_c_cast): Do cast on operand of EXCESS_PRECISION_EXPR.
        (build_modify_expr): Handle excess precision in RHS.
        (convert_for_assignment): Handle excess precision in converted
        value.
        (digest_init, output_init_element, process_init_element): Handle
        excess precision in initializer.
        (c_finish_return): Handle excess precision in return value.
        (build_binary_op): Handle excess precision in operands and add
        excess precision as needed for operation.
        * common.opt (-fexcess-precision=): New option.
        * config/i386/i386.h (X87_ENABLE_ARITH, X87_ENABLE_FLOAT): New.
        * config/i386/i386.md (float<SSEMODEI24:mode><X87MODEF:mode>2):
        For standard excess precision, output explicit conversion to and
        truncation from XFmode.
        (*float<SSEMODEI24:mode><X87MODEF:mode>2_1,
        *float<SSEMODEI24:mode><X87MODEF:mode>2_i387_with_temp,
        *float<SSEMODEI24:mode><X87MODEF:mode>2_i387, two unnamed
        define_splits, floatdi<X87MODEF:mode>2_i387_with_xmm, two unnamed
        define_splits, *floatunssi<mode>2_1, two unnamed define_splits,
        floatunssi<mode>2, add<mode>3, sub<mode>3, mul<mode>3, divdf3,
        divsf3, *fop_<mode>_comm_i387, *fop_<mode>_1_i387,
        *fop_<MODEF:mode>_2_i387, *fop_<MODEF:mode>_3_i387,
        *fop_df_4_i387, *fop_df_5_i387, *fop_df_6_i387, two unnamed
        define_splits, sqrt<mode>2): Disable where appropriate for
        standard excess precision.
        * convert.c (convert_to_real): Do not shorten arithmetic to type
        for which excess precision would be used.
        * defaults.h (TARGET_FLT_EVAL_METHOD_NON_DEFAULT): Define.
        * doc/invoke.texi (-fexcess-precision=): Document option.
        (-mfpmath=): Correct index entry.
        * flags.h (enum excess_precision, flag_excess_precision_cmdline,
        flag_excess_precision): New.
        * langhooks.c (lhd_post_options): Set
        flag_excess_precision_cmdline.
        * opts.c (common_handle_option): Handle -fexcess-precision=.
        * toplev.c (flag_excess_precision_cmdline, flag_excess_precision,
        init_excess_precision): New.
        (lang_dependent_init_target): Call init_excess_precision.
        * tree.c (excess_precision_type): New.
        * tree.h (excess_precision_type): Declare.

ada:
        * gcc-interface/misc.c (gnat_post_options): Set
        flag_excess_precision_cmdline.  Give an error for
        -fexcess-precision=standard for processors where the option is
        significant.

fortran:
        * options.c (gfc_post_options): Set
        flag_excess_precision_cmdline.  Give an error for
        -fexcess-precision=standard for processors where the option is
        significant.

java:
        * lang.c (java_post_options): Set flag_excess_precision_cmdline.
        Give an error for -fexcess-precision=standard for processors where
        the option is significant.

testsuite:
        * gcc.target/i386/excess-precision-1.c,
        gcc.target/i386/excess-precision-2.c,
        gcc.target/i386/excess-precision-3.c,
        gcc.target/i386/excess-precision-4.c,
        gcc.target/i386/excess-precision-5.c,
        gcc.target/i386/excess-precision-6.c: New tests.

Added:
    trunk/gcc/testsuite/gcc.target/i386/excess-precision-1.c
    trunk/gcc/testsuite/gcc.target/i386/excess-precision-2.c
    trunk/gcc/testsuite/gcc.target/i386/excess-precision-3.c
    trunk/gcc/testsuite/gcc.target/i386/excess-precision-4.c
    trunk/gcc/testsuite/gcc.target/i386/excess-precision-5.c
    trunk/gcc/testsuite/gcc.target/i386/excess-precision-6.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ada/ChangeLog
    trunk/gcc/ada/gcc-interface/misc.c
    trunk/gcc/c-common.c
    trunk/gcc/c-common.def
    trunk/gcc/c-cppbuiltin.c
    trunk/gcc/c-lex.c
    trunk/gcc/c-opts.c
    trunk/gcc/c-parser.c
    trunk/gcc/c-typeck.c
    trunk/gcc/common.opt
    trunk/gcc/config/i386/i386.h
    trunk/gcc/config/i386/i386.md
    trunk/gcc/convert.c
    trunk/gcc/defaults.h
    trunk/gcc/doc/invoke.texi
    trunk/gcc/flags.h
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/options.c
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/lang.c
    trunk/gcc/langhooks.c
    trunk/gcc/opts.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/toplev.c
    trunk/gcc/tree.c
    trunk/gcc/tree.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jsm28 at gcc dot gnu dot org]

------- Comment #127 from jsm28 at gcc dot gnu dot org  2009-03-30 01:57 -------
Fixed for C (and ObjC) for 4.5 with the new -fexcess-precision=standard
support.

The issue remains for other languages (and maybe for some m68k processors);
I quote from my original message
<http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html>:

  It would be possible to implement the option for non-C languages, to
  provide whatever predictable semantics are appropriate for those
  languages (whether or not described in their standards).  Note that
  bug 323 was originally reported with a C++ testcase.  If implemented
  for all languages, the option might supersede -ffloat-store.  Right
  now, -ffloat-store checks are scattered about the optimizers and it
  seems unlikely that -ffloat-store really implements any form of
  predictable semantics now; such semantic effect as it was intended to
  have could be better represented as an alias for a
  -fexcess-precision=standard option supported for all languages.  It
  would probably be most appropriate not to close bug 323 without having
  some form of predictable semantics available for each language.

and:

  I have not changed the m68k back end in this patch.  Thus the option
  may not be fully effective for the affected m68k processors (classic
  m68k with 68881, before 68040, only, not ColdFire, not 68040 or
  later).  If anyone wishes to make it fully effective for such
  processors they should copy the testcases to gcc.target/m68k/ and go
  through m68k insn patterns appropriately adjusting them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #128 from pinskia at gcc dot gnu dot org  2009-05-18 14:11 -------
*** Bug 40186 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ich at az2000 dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[ich at az2000 dot de]

------- Comment #129 from ich at az2000 dot de  2009-05-18 14:24 -------
I am a bit wondering if this bug is also for the case (a < b) && (b < a) ==
true. Is it?

Because if so, this becomes way more serious, as for example std::set<double>
is broken then (and depending on the STL implementation, it will throw
assertions then).

If not, I guess my bug #40186 is not a duplicate of this bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[nszabolcs at gmail dot com]

------- Comment #130 from nszabolcs at gmail dot com  2009-07-22 12:10 -------
(In reply to comment #129)
> I am a bit wondering if this bug is also for the case (a < b) && (b < a) ==
> true. Is it?

i guess so, see:

#include <stdlib.h> 
#include <stdio.h> 

#define axiom_order(a,b)  !(a < b && b < a) 
#define axiom_eq(a)       a == a 
#define third             ((double)atoi("1")/atoi("3"))

int main(void) {
        if (axiom_order(third, third))
                puts("ok");
        else
                puts("error");

        if (axiom_eq(third))
                puts("ok");
        else
                puts("error");

        return 0;
}


here this prints
error
error
with gcc 4.2 and -S shows that this is long double vs double precision problem


> Because if so, this becomes way more serious, as for example std::set<double>
> is broken then (and depending on the STL implementation, it will throw
> assertions then).

in C99 (+TC1,TC2,TC3) different precision is not allowed

5.1.2.3 p12:
  ... In particular, casts and assignments are required to perform their
specified conversion

5.2.4.2.2 p8:
  Except for assignment and cast (which remove all extra range and precision),
the values 8 of operations with floating operands and values subject to the
usual arithmetic conversions and of floating constants are evaluated to a
format whose range and precision may be greater than required by the type.

i'm not sure about c++ though


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[vincent at vinc17 dot org]

------- Comment #131 from vincent at vinc17 dot org  2009-07-22 17:33 -------
(In reply to comment #130)
> #define axiom_order(a,b)  !(a < b && b < a) 
> #define axiom_eq(a)       a == a 
> #define third             ((double)atoi("1")/atoi("3"))
[...]

> in C99 (+TC1,TC2,TC3) different precision is not allowed

It is allowed, except for...

> 5.1.2.3 p12:
>   ... In particular, casts and assignments are required to perform their
> specified conversion

But a division is not a cast, nor an assignment.

> 5.2.4.2.2 p8:
>   Except for assignment and cast (which remove all extra range and precision),
> the values 8 of operations with floating operands and values subject to the
> usual arithmetic conversions and of floating constants are evaluated to a
> format whose range and precision may be greater than required by the type.

A greater precision is OK for division, in particular.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[ich at az2000 dot de]

------- Comment #132 from ich at az2000 dot de  2009-07-22 20:54 -------
So that means that this C++ example could crash under certain circumstances
(depending on how far the compiler is optimising here)?

#include <set>
#define third             ((double)atoi("1")/atoi("3"))
int main() {
  std::set<double> m;
  m.insert(third);
  m.insert(third);
  return (m.find(third) != m.end()) ? 0 : 1;
}


Because this example only works if it is guaranteed that !(third < third &&
third > third), otherwise it would abort. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #133 from pinskia at gcc dot gnu dot org  2009-09-20 21:28 -------
*** Bug 41195 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mehta at roguewave dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jsm28 at gcc dot gnu dot org]

------- Comment #134 from jsm28 at gcc dot gnu dot org  2009-10-29 20:26 -------
*** Bug 41867 has been marked as a duplicate of this bug. ***


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tydeman at tybor dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jsm28 at gcc dot gnu dot org]

------- Comment #135 from jsm28 at gcc dot gnu dot org  2009-10-31 18:37 -------
*** Bug 41867 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #136 from pinskia at gcc dot gnu dot org  2010-05-19 18:05 -------
*** Bug 44198 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |AlekM at hotmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jvdelisle at gcc dot gnu dot org]

------- Comment #137 from jvdelisle at gcc dot gnu dot org  2010-08-04 02:42 -------
*** Bug 45175 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |CycleTimeChart at yahoo dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Comment #138 from pinskia at gcc dot gnu dot org  2010-09-16 17:08 -------
*** Bug 45691 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at macky dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-22 15:48 -------
*** Bug 24014 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |u dot strempel at gmx dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-16 13:22 -------
*** Bug 23318 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-15 21:23 -------
*** Bug 23407 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dir at lanl dot gov


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-09 15:59 -------
*** Bug 23298 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsell at agleader dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-10 18:09 -------
*** Bug 22394 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glenn at aoi-industries dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-19 12:18 -------
*** Bug 1098 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |green at rhythm dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-06-19 11:09 -------
...to end this pointless discussion.

Some people call this a bug in the x87 series.  Other call it a bug in
gcc.  See these mails at least for the reason why this could be considered
a bug in gcc: 
http://gcc.gnu.org/ml/gcc/2003-08/msg01195.html
http://gcc.gnu.org/ml/gcc/2003-08/msg01234.html
http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html

Regardless of where one wishes to put the blame, this problem will _not_ be
fixed.  Period.



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-06-19 11:05 -------
Reopening...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 19:56 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 19:47 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 19:43 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 19:35 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 19:24 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 19:06 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 18:27 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-29 16:24 -------
*** Bug 21809 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |themis_hv at yahoo dot co
                   |                            |dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[cognot at earthdecision dot com]

------- Additional Comments From cognot at earthdecision dot com  2005-05-20 10:03 -------
(In reply to comment #59)
> 
> I had this bug on x86 architecture, with no optimization of the code (no -OX)
> and with float-store on. My workaround was to store the return of the double
> function in a auxliar double variable before comparison.
> Have you an other suggestion ?
> 

The way I've "fixed" (more like avoided) this problem is to have:

#include <fpu_control.h>

void set_math_double_precision() {
  fpu_control_t fpu_control = 0x027f ;
  _FPU_SETCW(fpu_control);
}

and make sure this function is called before doing any FP operations. It only
needs to be called once.

Richard.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[mario dot tragni at planetek dot it]

------- Additional Comments From mario dot tragni at planetek dot it  2005-05-20 08:40 -------
(In reply to comment #2)
> State-Changed-From-To: open->closed
> State-Changed-Why: See any faq on numerical analysis that mentions the x86.
>     You are seeing the results of excess precision in the FPU.
>     Either change the rounding precision in the FPCR, or work
>     around the problem with -ffloat-store.
> 

I had this bug on x86 architecture, with no optimization of the code (no -OX)
and with float-store on. My workaround was to store the return of the double
function in a auxliar double variable before comparison.
Have you an other suggestion ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-20 03:00 -------
*** Bug 7719 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petr dot savicky at cuni dot
                   |                            |cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 14:17 -------
*** Bug 20674 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 21:53 -------
*** Bug 20674 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piaget at us dot ibm dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-17 13:37 -------
*** Bug 20026 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |denis dot nagorny at intel
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-09 06:35 -------
*** Bug 19837 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wirawan0 at softhome dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-28 19:07 -------
*** Bug 19675 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-28 18:47 -------
*** Bug 19675 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cognot at earthdecision dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-17 15:40 -------
*** Bug 19469 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |debian-gcc at lists dot
                   |                            |debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-15 15:10 -------
*** Bug 19011 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-15 14:05 -------
*** Bug 19011 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |konstantin at mysql dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-02 14:22 -------
*** Bug 18784 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Graham dot Murphy at jhuapl
                   |                            |dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[eda-qa at disemia dot com]

------- Additional Comments From eda-qa at disemia dot com  2004-12-01 16:24 -------
To summarize, this defect effectively states that:

assert( (x/y) == (x/y) )

may cause an assertion if compiled with optimization.

While I understand why it happens, that doesn't mean it isn't a defect.  This
makes it impossible to turn on the optimizer with any code using floating point
and still expect to get a correct result.  Perhaps in some situations this is
okay, but in general this is not.

This would also mean the following are also invalid code -- which I'm fairly
certain the C/C++ standards would state otherwise:

a = (x/y);
assert( a == x/y ) //may Abort

if( a == x/y )
  assert( a == x/y )  //may Abort

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-19 15:33 -------
*** Bug 18567 has been marked as a duplicate of this bug. ***
------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-01 15:12 -------
*** Bug 18756 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eda-qa at disemia dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-19 15:32 -------
*** Bug 18567 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benoit dot sibaud at rd dot
                   |                            |francetelecom dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[jonathan at csse dot uwa dot edu dot au]

------- Additional Comments From jonathan at csse dot uwa dot edu dot au  2004-10-04 10:57 -------
Some musings based on my encounter with this bug...

Comparison of doubles is not just restricted to numerical analysis.  Bug report
17802 (aka #323) arose out of a binary search of a timer queue.  Is it wrong to
assume that if "int secs = 2" and "int usecs = 100000" then "secs + 1e-6 *
usecs" will return the same result every time it is evaluated as an inline function?

Calling a trivial function twice with an identical parameter may return a value
less than, equal to or greater than itself (depending on register allocation in
the context of the calls).  This is a really nasty piece of nondeterministic
behaviour.  Weren't compilers and "high level" languages invented to get around
exactly this kind of hardware dependency?

Compiling with -ffloat-store did not help in my case.  Compiling without -O
isn't always possible either.  Since the function that causes the problem is the
trivial calculation above, inlined for performance, I can't guarrantee that
every user of the header file it appears in will know to compile without -O (or
be willing to).  The outcome will be users reporting a bug in my code.

This bug is being reported regularly, and probably affecting a lot more people
that don't report it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[sliwa at cft dot edu dot pl]

------- Additional Comments From sliwa at cft dot edu dot pl  2004-10-03 15:52 -------
Excessive precision should be discarded before performing any comparison. It is
done e.g. by the Intel fortran compiler. -ffloat-store rounds only the values
stored in a variable, and in some situations may trigger instead of suppressing
the bug. Existing numerical software packages (e.g. LAPACK and SLATEC fortran
libraries) fail their tests with gcc just due to this issue.
So it is a bug, even if almost all other compilers reproduce it.
If you refer me to a FAQ on numerical analysis, please note that the FAQ states
things as they are, and not as they should be.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-03 14:54 -------
*** Bug 17802 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathan at csse dot uwa dot
                   |                            |edu dot au


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-23 09:21 -------
*** Bug 16686 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernert at planet dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[zack at gcc dot gnu dot org]

------- Additional Comments From zack at gcc dot gnu dot org  2004-07-19 03:22 -------
*** Bug 16607 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-19 01:19 -------
*** Bug 15386 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |diego at biurrun dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-17 22:29 -------
*** Bug 16607 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-17 17:40 -------
*** Bug 16607 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |npr1 at suomi24 dot fi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-27 19:46 -------
*** Bug 16223 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc-erikd at mega-nerd dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-06 18:13 -------
*** Bug 15852 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sliwa at theta1 dot cft dot
                   |                            |edu dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-14 16:54 -------
*** Bug 15437 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lani at oas dot ca


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323