[Bug target/97040] incorrect fused multiply add/subtract instruction generated from C code

["law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97040

--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So a bit more background.  I was doing some maintenance work on the v850 a few
years back and noticed an issue with e3v5 testing and FMAs.  I poked around a
bit and had largely ruled out the generic bits of FMA generation as the
problem.  But I was very short of time and didn't have reasonable docs on the
implementation of FMAs for the newer versions of the v850 (e3v5 was added long
after I did the original port).  Renesas's site isn't great for finding the
relevant docs as you have to map from something like e3v5 to a part within the
v850 family:(

SO I set it aside.  You report caused me to dig a bit further.  I finally found
a mapping from e3v5 to a specific part on Renesas's site (RH850G3KH) and was
able to review the specification of these instructions.

Again I managed to convince myself that our gimple FMA generation was correct. 
I also convinced myself that the RTL patterns for the v850 match the
documentation from Renesas.   Then it finally hit me.

The v850 patterns are using pattern names that require specific semantics.  ie,
if the expanders see a pattern fnma<mode> they expect that pattern will
implement very specific semantics.  In particular they expect that the negation
will apply to one of the arguments to the multiplication.   But the instruction
emitted in those patterns negates the final result.  ie, GCC expects this
semantic from the fnma<mode> pattern

  (fma (neg op0) (op1) (op2))

But the v850 chip implements

  (neg (fma (op0) (op1) (op2)))

So the bug is using the "fnma" and "fnms" names for those patterns.  The RTL is
fine, it's strictly a pattern naming issue.