https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- 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).
