Today I came across a strange problem on my secondary machine running Ventura/Xcode 14. In my dsp code I use infinite double values to mark analogue poles/zeros placed at infinity.
Other parts of the code check this using std::isinf(double).
During performance testing I ramped up the optimisation settings to -Ofast, which includes -ffast-math and a bunch of other math stuff - including not caring too much about nan and inf values in math routines. So far (on older versions of Xcode) this has never been a problem and std::isinf(double) still worked. Something seems to be different on Xcode 14.1+ and I am now getting false for +inf values. It seems the test is completely bypassed. Initially I thought something was wrong with my Xcode 14.1 installation and I downloaded and installed 14.2 - just to see no difference. Unfortunately I don’t have another Ventura machine to verify this.
Has anyone seen that as well? At least in my case it broke my dsp code in a terrible way… ironically producing +inf output samples.
I stopped using fast-math with clang, it has caused me too many issues. With fast-math, clang considers that Inf or NaN values will never occur ( -ffast-math implies -ffinite-math-only ) so all your safeguards trying to detect inf or nan are bypassed by the compiler. I also had at one time an even worse behaviour where std::sqrt(1e-40f) would return -inf. The very small performance gain is absolutely not worth the drawbacks of fast-math .
The performance gain depends on what the code is doing. I have some dsp code where it makes a lot of difference (30% speedup) and I’d like to keep it on at least for those parts. Before switching to CMake I left -ffast-math on at all times to catch these weird bugs as early as possible.
In the meantime I saw some discussions on LLVM forums about my specific problem and the new-ish behaviour of just bypassing isinf (and isnan it seems…) is especially troublesome if code receives floating point values from other code/files/the network and wants to make sure the data is sound.
So -Ofast users beware… in the Juce sources (v6.1.6) there’s one instance of std::isinf in the svg parser that’s affected by this - not a real problem.
yes, AppleClang 13 and 14, but maybe it depends in the libc++ version as well?
It seems gcc has been this way for a long time… so for me the lesson is to not trust std::isnan, std::isinf and std::fpclassify if math optimisations are used.