s__mac

The bummer about this to me is that the c99 guys took it upon themselves to extend IEEE semantics to complex numbers. To do that, you have to decide on a representation for infinity in complex numbers (there's really only one mathematically). They choose isinf(re(x)) || isinf(im(x)), so among other things, Inf + Nan*i is considered infinite...ok. And then they tried to make things consistent between real and complex numbers with this (made up) notion of complex infinity.

The result being that there's edge cases they have to back up and 'fix' to be consistent. However, they could have just decided that complex arithmetic semantics follow naturally from floating point and whatever results ensue. So in the end this was all self-inflicted.

I submitted a bug report to GCC:

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

Even though it's not a real bug, it's a missed optimization. My pitch is to emit the code to do the multiplication, and only call a fixup function when the results are NaN. If you short-circuit the NaN check, you only need 3 pretty cheap instructions to decide to call the standard library for help, and you can avoid it in the vast vast majority of cases. This should make multiplication and division much faster in the default case. Naturally the checks would still be elided with -fcx-limited-range is on.