Weird compiler bug – Same code, different results
blog.zaita.com
Weird compiler bug – Same code, different results
1–10 of 41 posts
Re: Weird compiler bug – Same code, different results
#2Do not use C/C++ for numerical code where accuracy is needed. These languages are not specified to conform to IEEE 754 and you are absolutely asking for trouble.
Re: Weird compiler bug – Same code, different results
#3I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?
Re: Weird compiler bug – Same code, different results
#4If you read the article you find that this is a bug in MinGW64 libraries.
It's not a compiler bug, it's not a problem in C/C++, or even in IEEE-754 floating point math. The MinGW64 thread library simply forgot to initialize the FPU correctly.
He'd have had the same problem if he wrote his code in assembly language and then ran it in a MinGW64 thread.
Re: Weird compiler bug – Same code, different results
#5I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?
Things like rounding mode and denornal behavior could be controlled by CPU flags. Imy not familiar with x86, but this is defiy the case in PPC.
Re: Weird compiler bug – Same code, different results
#6> This means that floating point arithmetic is non-associative. In that A + B != B + A.
The equation is the commutative property, not associative. IIRC addition in IEEE-754 is commutative.
The property that fails is (A+B)+C = A+(B+C).
Re: Weird compiler bug – Same code, different results
#7I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?
Probably the author is accidentally getting 80-bit "extended double" arithmetic.
Re: Weird compiler bug – Same code, different results
#8Do not use C/C++ for numerical code where accuracy is needed. These languages are not specified to conform to IEEE 754 and you are absolutely asking for trouble.
My copy of C11 says
Annex F
(normative)
IEC 60559 floating-point arithmetic
F.1 Introduction
This annex specifies C language support for the IEC
60559 floating-point standard [...] previously designated
ANSI/IEEE 754-1985.Re: Weird compiler bug – Same code, different results
#9I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?
Some kind of internal state specific to Microsoft's libm? It doesn't look like _fpreset() is present anywhere else.
Though in general, IEEE-754 math does have a small amount of global state, for stuff like rounding modes and subnormals. Perhaps the spawned thread's fenv was unexpected.
I'm not super convinced by this blog post anyway, since it immediately confuses associativity with commutativity.
Re: Weird compiler bug – Same code, different results
#10I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?
The processor itself supports configuring some aspects of floating point behavior; on x86 this is the MXCSR register. The most important one is rounding mode: you can choose round-to-nearest, round-down, round-up, or round-towards-zero. Less common options include whether to raise an exception on various out-of-range conditions, and whether to treat denormal numbers as zero (faster but less accurate and not IEEE 754 compliant).
The C standard library has functions to do this configuration; search for fesetenv. _fpreset is not a standard function but, at least in Wine's implementation [1], just resets the relevant configuration registers to an initial state.
[1] https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2...