libstdc++ uses a different signaling NaN than the MSVC STL does

[PathogenDavid]

The implementation of std::numeric_limits<float>::signaling_NaN is different between GCC's libstdc++ and MSVC STL

https://github.com/microsoft/STL/blob/e745bad3b1d05b5b19ec652d68abb37865ffa454/stl/inc/limits#L904

https://github.com/gcc-mirror/gcc/blob/6b096c17314a46f285fa26670048f287a399573f/libstdc%2B%2B-v3/include/std/limits#L1720

The Microsoft implementation results in 0x7f800001 and the GCC one gives 0x7fa00000.

Similar story for doubles.

This is causing Float_Nan_Signaling4 and Double_Nan_Signaling4 to break.

According to this: https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Other-Builtins.html#index-g_t_005f_005fbuiltin_005fnans-1871 __bultin_nans is the same as nans as defined by N965, which leaves the value totally up to implementation. (Additionally Wikipedia seems to suggest that signaling NaNs in general are up to implementation.)

The Intel developer's manual Volume 1 §4.8.3.4 defines the difference between quiet and signal NaNs as follows:

A QNaN is a NaN with the most significant fraction bit set; an SNaN is a NaN with the most significant fraction bit clear.

ARM defines it in IEEE 754 standard implementation choices and thankfully matches Intel (although it's worded opposite just to make me worry for a second, lol):

A most significant fraction bit of zero indicates a Signaling NaN (SNaN). A most significant fraction bit of one indicates a Quiet NaN (QNaN).

Both 0x7f800001 and 0x7fa00000 fit both descriptions. (Oddly enough, the GCC code above in MSVC results in 0x7fe00000 which is a quiet NaN, not sure what's up with that. I guess it doesn't want an empty string.)

I think the fix here will just be for those tests to check if the bit pattern matches a signaling NaN at all as per Intel and ARM's definitions since we don't actually care for the specific signaling NaN in those two tests. (We have other tests which request a specific signaling NaN to cover that.)