Comment 12 for bug 1266571

The algorithm isn't expecting to use FMA; it's just treating
floating-point numbers as approximate real numbers. I'm not sure why
multiplication has TRUNC, but my guess is it's about excess range not
precision - excess precision would improve results, but excess range in
only one of two numbers added/subtracted could result in an infinity of
the wrong sign as a result on overflow.

The division for scaling is, as commented, inferior to scalbn / logb
approaches as in Annex G, but to use such logarithmic scaling would
require appropriate built-in functions for scalbn / logb supported with
inline expansion on the target. Even then, accuracy in the sense of at
most a few ulps error in real and imaginary parts separately requires fmma
(a*b + c*d) as the atomic operation, not fma; without that, you have the
more complicated task (if you want that accuracy) of constructing
(approximate) fmma out of available operations such as fma.

It's true that now we have full __builtin_isnan / __builtin_isfinite /
__builtin_isinf those macros for the complex functions should probably use
them.

As noted above, one could consider proposing complex multiplication /
division with better / better defined accuracy (or other new facilities)
for the next revision of the C standard. Proposals for C2x can be made
over the next few years (we don't actually have a C2x working draft yet,
just a C17 bug-fix version being reviewed, but you can still make C2x
proposals).