`<cmath>`: `constexpr` `fpclassify()` rejects signaling NaNs on x86

[StephanTLavavej]

I could probably work around this in the library by using a bit_cast, but it would be better for the compiler to fix this bug.

D:\GitHub\STL\out\x86>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.52.36725 for x86 (PREVIEW)
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

D:\GitHub\STL\out\x86>type meow.cpp

#include <cassert>
#include <cmath>
#include <limits>

#ifndef _M_IX86
static_assert(false, "Use x86 to repro this failure!");
#endif

constexpr bool test() {
    assert(std::fpclassify(std::numeric_limits<double>::signaling_NaN()) == FP_NAN);
    return true;
}

int main() {
    static_assert(test());
}

D:\GitHub\STL\out\x86>cl /EHsc /nologo /W4 /std:c++latest /Zc:cmath meow.cpp
meow.cpp
meow.cpp(15): error C2131: expression did not evaluate to a constant
D:\GitHub\STL\out\x86\out\inc\__msvc_math.hpp(321): note: failure was caused by a library call raising a floating-point exception
meow.cpp(15): note: the call stack of the evaluation (the oldest call first) is
meow.cpp(15): note: while evaluating function 'bool test(void)'
meow.cpp(10): note: while evaluating function 'int _Msvc_math::fpclassify(double) noexcept'

[ayushsshukla]

I'd like to investigate this issue. Is the preferred fix expected to be on the compiler side, or should fpclassify be changed to avoid the floating-point exception during constant evaluation (e.g. using bit_cast)?

I'd be happy to dig into this and work on a PR. Could you assign it to me?

[StephanTLavavej]

I want the compiler to fix this.