https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52889
--- Comment #3 from MathiasPuetz at gmx dot de --- Hi Andrew, I only vaguely remember this after 11 (!) years. The generated code looks ok on first sight. However the reference doc (e.g. https://www.cs.ucr.edu/~csong/cs153/refs/amd64-vol4-media.pdf 581) shows a different operand order for the vfnmsubpd instruction than the output of the GNU assembler (vfnmsubps dest,a,b,c vs. c,b,a,dest) This could just be a peculiarity of GNU assembly mnemonics definitions. You should check the results of the code though A=1 B=2 c=3 Should return 3-1*2=1 according to AMD ref guide. Just looking at the code won’t tell. I remember that I checked with the Intel compiler as well, and got the expected result using the same intrinsic code. When I tried with GNU, I didn’t, which caused me to investigate. I can’t tell, if the AMD ref guide document is actually correct. Maybe there was an erratum, that I am not aware of, and Intel rectified this in their intrinsic definitions. If the code doesn’t produce the expected result, you would need to talk to AMD to get to the bottom of this (the mistake might be in their docs). Anyway, AMD still supports FMA4 code on their latest Epyc CPUs. Most new binaries won’t run into the issue, as newer compilers would rather generate AVX256/512 instructions, which are faster on newer hardware. So it’s not 100% obsolete, but it’s indeed unlikely that someone would practically run into this except for comparing some old benchmarks after so many years. Mathias ParTec AG
