Std::numeric_limits<double>::infinity();

Infinity is not undefined if you compile with fastmath, which so far I assume is still neccessary for high performance audio applications. I get a ton of warnings lately about this.

What warnings do you get?

It’s unclear exactly what this thread is asking or proposing.

I disable fastmath but add several other flags back:

if (MSVC)
    # fast math and better simd support in RELEASE
    # https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior?view=msvc-170#fast
    target_compile_options(SharedCode INTERFACE $<$<CONFIG:RELEASE>:/fp:precise>)
else ()
    # See the implications here:
    # https://stackoverflow.com/q/45685487
    target_compile_options(SharedCode INTERFACE $<$<CONFIG:RELEASE>:-O3 -ffp-contract=fast -fno-signed-zeros -freciprocal-math>)
endif ()
1 Like

Ok, I was just assuming that this is so obvious, that I thought those have seen these warnings, will understand. Lately, when you you are on the latest Xcode version (and already before) the use infinity started to produce warnings. Because this is used in fundamental Juce classes, you see a lot of these warnings. My post was about questioning the choice of infinity for this purpose in an audio application. std::numeric_limits::max(); works as well and does not have the issue of being undefined on Arm with fastmath option active. To my knowledge this is still a neccessity if performance is of utmost importance, which it is for us, when playing 100ths of sampler voices at once. The warning is: Use of infinity is undefined behavior due to the currently enabled floating-point options

Did you profile that ?