https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #6 from Freddie Chopin <freddie_chopin at op dot pl> --- > On a newer Intel (or AMD) machine, add -march=naitve and you will > see the same behavior. You are right, adding that switch causes the assert to appear... > VFMA is not just multiply and accumulate but rather fused multiply and add. > The multiplication is done in infinite precision and then the add is done > in that same infinite precision and then a round happens down to double. > Instead of what happens with -ffp-contract=off which is not to used the > fused multiple add instruction which means round between the multiply and > addition. I've read that info already, but in my (limited) understanding subtracting two identical numbers still gives 0 at infinite precision, no matter how you round the result ); But I get your point - somehow after re-arranging the whole sequence, the result got inexact (from my point of view). Any advice how to handle this problem in this particular code? I'd prefer not to just set "-ffp-contract=off" for my whole project, as the toolchain libraries are compiled with contracting enabled anyway (I see A LOT of VFMA in functions like sinf() or cosf()), so that "solution" would be partial at best. Is there any "generic" way to write code that would allow the result to be "correct", possibly by also allowing optimizations which don't change accuracy?
