[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 Andrew Pinski changed: What|Removed |Added Target|32-bit X86 on Linux |i?86-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-11 Component|c |middle-end Ever Confirmed|0 |1 --- Comment #4 from Andrew Pinski 2012-09-11 18:48:50 UTC --- And we need a testcase.
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 --- Comment #5 from Veiokej 2012-09-12 03:28:43 UTC --- Johnathan, Yes, I've read the floating point nonbug stuff. This isn't a nonbug. Michael, I understand your point, and thanks for the command line option. However, this is a subtly different issue than saying "64-bit double precision is slightly more accurate on X86 platforms due to 80-bit temporaries, vs. X64 platforms". The reason it's different is because there is no math done, and 80-bit precision can hold 100% of 64-bit values with no loss of precision. So no matter what, my equality test should not fail. Andrew, I appreciate that. Let me see if I can come up with something short of uploading the entire codebase. It's extremely sensitive to neighboring code, and is thus hard to isolate.
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 --- Comment #6 from Veiokej 2012-09-12 04:14:52 UTC --- In the process of trying to create a demo, I think I found the problem. Indeed, no math is taking place between when the value X is first computed and stored to the list, and when it's compared for equality with the nearest value Y found in the list. (They should be identical.) I think that X is observed to be unequal to Y because X is cached in a register, despite the fact that Y is computed in a (later) function. (Evidence is that removing -finline_functions, as does -ffloat-store fixes the problem.) When I was printing the value previously, I was inadvertently causing both X and Y to be stored to memory as 64-bit doubles, then taking the difference after the fact, which of course turned out to be 0. The difference was actually closer to 6x10^(-17). So this demonstrates how the previously well known excess precision issue can actually cause equality testing to fail, even when no math is involved between the store to memory, and the compare with memory. Yikes! Thankfully this is fixable by using full 80-bit precision, or migrating to X64. Let's leave this on the record for documentation, but I don't think it's worth further pursuit. Thanks to all for your input.
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #7 from Richard Guenther 2012-09-12 09:22:42 UTC --- Closing.
