Complex signed NaN test fails on Darwin/Aarch64

[Keno]

Test Failed at /Users/julia/julia23/test/complex.jl:1049
  Expression: isequal(one(T) / complex(T(Inf), T(-NaN)), complex(zero(T), zero(T)))
   Evaluated: isequal(0.0f0 - 0.0f0im, 0.0f0 + 0.0f0im)
Test Failed at /Users/julia/julia23/test/complex.jl:1054
  Expression: isequal(one(T) / complex(T(-Inf), T(-NaN)), complex(-(zero(T)), zero(T)))
   Evaluated: isequal(-0.0f0 - 0.0f0im, -0.0f0 + 0.0f0im)
Test Failed at /Users/julia/julia23/test/complex.jl:1067
  Expression: isequal(one(T) / complex(T(-NaN), T(Inf)), complex(-(zero(T)), -(zero(T))))
   Evaluated: isequal(0.0f0 - 0.0f0im, -0.0f0 - 0.0f0im)
Test Failed at /Users/julia/julia23/test/complex.jl:1071
  Expression: isequal(one(T) / complex(T(-NaN), T(-Inf)), complex(-(zero(T)), zero(T)))
   Evaluated: isequal(0.0f0 + 0.0f0im, -0.0f0 + 0.0f0im)

The reason for this seems to be that Apple turns on the RunFast flag, which normalizes away the sign bit of the NaN on certain operations. The question is to what extent we want to allow that or do we need to turn off RunFast or adjust the test or one of the implementations? Note that these tests do pass for Float64, only Float32 is at issue.

cc @stevengj

[Keno]

In particular zero_subnormals is also on on this platform, so we should decide if that's what we want.

[Keno]

Or maybe we want to turn on zero_subnormals by default everywhere, since that's where things seem to be going.

[oscardssmith]

Wait what? Is zeroing subnormals even ieee 704 compliant?

[Keno]

No, it isn't, but subnormals are hard to handle and cost 100-1000x as much as regular operations on modern hardware, so most ISAs not have a bit you can flip to zero them and not pay the cost. It's off by default on Aarch64 linux, so maybe we should just turn it off on Darwin also, but I figured it'd be worth taking an explicit call on that.

[oscardssmith]

Note that removing subnormals breaks error compensation, and most of the theorems about floating point arithmetic

[Keno]

I guess the safe thing for now is just to turn off the fast flags, and maybe later we can add them back together with a nicer API for actually using them. We do support changing the flag right now (even on x86), but the compiler doesn't actually respect it, so it doesn't really work.