https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #4 from Freddie Chopin <freddie_chopin at op dot pl> --- Hello Andrew and thanks for your answer. Generally I don't care about the sequence of operations or the exact instructions that get generated, but in this case this default behaviour produces invalid results. Generally the whole calculations are like this: mx = ex - sx; my = ey - sy; distance = sqrtf(mx * mx + my * my) * constant; The important thing here is that ex and sx are bitwise identical, just as ey and sy. Thus everything above can be transformed to: mx = x - x; my = y - y; distance = sqrtf(mx * mx + my * my) * constant; and then: mx = 0; my = 0; distance = sqrtf(0 * 0 + 0 * 0) * constant; However you rearrange that, the expected result is 0 and I see no place for "typical" floating point inaccuracies here. Let me reiterate - "startVector" and "endVector" in my test case are bitwise identical. Yet the code produces 1.34925369e-06 at the end... The same code compiled at -O2 for x86-64 does not assert. I don't know x86-64 assembly, but I'm pretty sure that it supports this kind of instructions. If the results of VFMA are considered "good enough" I think that the default value of -ffp-contract should be changed to "off" - after all -funsafe-math-optimizations or -ffast-math are not enabled by default either. BTW - VFMA is used also with "-std=c++11". Thus I think that the bug is not invalid and I ask you to reconsider. Thanks in advance!
