Weird compiler bug – Same code, different results

Post by cperciva » Sat, Jan 30, 2021, 1:33 AM UTC

cozzyd wrote: post #28

cperciva wrote: post #7

Earlier quoted context omitted.

Probably the author is accidentally getting 80-bit "extended double" arithmetic.

That should be clear from looking at the assembly, shouldn't it? Don't think the floating point environment can change that but I could be wrong. Floating-point rounding modes seem more likely to me. The author should be able to dump the floating point configuration to confirm, I'm sure.

Post by shakna » Sat, Jan 30, 2021, 2:15 AM UTC

jcranmer wrote: post #16

titzer wrote: post #2

Do 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.

In practice, all of the C compilers will (or can be made to) conform to IEEE 754, although #pragma STDC FENV_ACCESS ON support is very spotty (and consequently non-default rounding-mode support), although Clang/LLVM has been working on this for the past several months. (That reminds me, I need to harangue the llvm-libc folks to add that pragma to their fpenv code for correctness sake).

Post by ojnabieoot » Sat, Jan 30, 2021, 3:41 AM UTC

zaitanz wrote: post #20

gus_massa wrote: post #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).

Op Here. Yes you are correct. Been very sleep derived when I wrote this (newborns eh). I'll update this. I didn't want to go too far into the background of floating point math in the post as it wasn't ultimately the issue, just something I was mindful of.

Post by zaitanz » Sat, Jan 30, 2021, 6:42 AM UTC

ojnabieoot wrote: post #35

zaitanz wrote: post #20

Earlier quoted context omitted.

Op Here. Yes you are correct. Been very sleep derived when I wrote this (newborns eh). I'll update this. I didn't want to go too far into the background of floating point math in the post as it wasn't ultimately the issue, just something I was mindful of.

I think you made the wrong correction in the article: > Update: Thanks to gus_massa and wiml @ HackerNews for pointing out I had used associative instead of commutative.... This means that floating point arithmetic is noncommutative [i]n that A + B != B + A. Floating-point arithmetic is commutative, but not associative. So for floating-point numbers, A + B = B + A always, but A + (B + C) != (A + B) + C in many cases.…

Post by lysium » Sat, Jan 30, 2021, 8:31 AM UTC

comex wrote: post #10

lysium wrote: post #3

I 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…