The bug is about two related floating-point concepts: contraction and excess precision.<p>The C and C++ standards mandate that floating-point operations follow the IEEE-754 spec. For example, the result of any elementary operation (+, -, *, /) must be the floating-point number "closest" to the exact result of the operation, for some definition of "closest" (i.e., according to a user-modifiable rounding mode). If we denote this rounding operation by fp64(), then the C code<p><pre><code> double x = a + b
</code></pre>
results in<p><pre><code> x := fp64(a + b)
</code></pre>
Furthermore, the C code<p><pre><code> double y = a + b * c
</code></pre>
results in<p><pre><code> y := fp64(a + fp64(b * c))
</code></pre>
These restrictive definitions have the huge advantage of allowing portability and determinism of floating-point operations: regardless of the platform, architecture, or compiler, the values of x and y are mandated down to the bit representation. Also, this most often does not come at any performance cost, since most architectures have IEEE-754-compliant instructions.<p>But then, there are exceptions. For example, the old x87 FPU instructions would allow one to do:<p><pre><code> y := fp64(a + fp80(b * c))
</code></pre>
where fp80() uses the internal 80-bit x87 FPU registers. This is "excess precision" (80 instead of 64 bits), and this would generally be faster than the standard-compliant code. A more recent example, since Haswell, Intel CPUs have builtin fused multiply-add (FMA) instructions, allowing one to eschew the inner rounding altogether:<p><pre><code> y := fp64(a + b * c)
</code></pre>
This is a case of "contraction" in GCC parlance, and it is also generally slightly faster that the standard-compliant code.<p>Both "excess precision" and "contraction" seem like win-wins: more accuracy and more performance. However, since we cannot not control exactly when the compiler applies them and when it does not, it comes at the cost of portability / determinism / reproducibility. Even just a compiler version change could give you (slightly) different results.<p>By default (in "GNU" mode), GCC enables both excess precision and contraction. However, in C, it now exposes command-line options to disable them. Also, specifying a standard (e.g. -std=c99) disables them both. However, no such option existed in C++. From the man page:<p><pre><code> -fexcess-precision=standard is not implemented for languages other than C.
</code></pre>
The commit linked in the bug report adds the options for C++.*