Update PAL libc math function introspection to be exact

[tannergooding]

As per #35325 (comment), a few of the PAL libc math function checks are validating that the result is "close enough". However, IEEE floating-point is meant to be deterministic, if nothing else, and so the result should be exact or it should fallback to the specialized handling.

[janvorli]

@tannergooding I've set the milestone for this as 6.0.0, please feel free to change it if you disagree.

[janvorli]

@tannergooding do you have a plan to fix this for 6.0?

[davidwrighton]

@tannergooding, while these functions are well defined, the C standard does not actually specify that they have exact defined behavior across implementations. In particular, looking at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf I can see that in section 7.31.8 there is a future direction to add a function called cr_atan2 which will require a correctly rounded result, and in section 5.2.4.2.2 Characteristics of floating types<float.h>, there is a statement that "The accuracy of the floating-point operations (+,- , *, /) and of the library functions in <math.h> and <complex.h> that return floating-point results is implementation-defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that the accuracy is unknown. Decimal floating-point operations have stricter requirements."

[tannergooding]

the C standard does not actually specify that they have exact defined behavior across implementations.

Yesn't. The C standard allows for variance, unless you claim IEEE 754 conformance and then Annex F - IEC 60559 floating-point arithmetic (IEC 60559 == IEEE 754) kicks in and you start having much stricter requirements. In particular the size and accuracy of float and double become strictly the IEEE 754 binary32 and binary64 types; long double remains semi "implementation defined".

The runtime currently requires and expects IEEE 754 conformance for all the basic operations and many of the optimizations we perform. We explicitly removed all the "wrong" x87 FPU support that used to exist and I don't expect we will ever add it back (and I would push very strongly against us ever attempting to do so, it would push us in a negative direction).

C23 and C++23 are both doing a large push for IEEE 754 conformance, such that they are defining new binary16, binary32, binary64, and binary128 types as well as corresponding float16_t, float32_t, float64_t, and float128_t typedefs where there is a strict requirement that these be IEEE 754 conformant as well as standardizing and stabilizing information about whether "fast math" (which are non IEEE 754 compliant) optimizations are enabled or disabled.

Even pre C23 and C++23 (which of course aren't finalized yet), Annex F has fairly strict requirements for these operations and the required result for key inputs (often 0, NaN, +/-Infinity, and other key values, depending on function). But as they are IEEE 754 compliant, there is an implied requirement that they return the "infinitely precise result". Historically, the runtime has enable /fp:fast equivalent behavior for the C Runtime math functions which allows them to deviate, and this issue is tracking us ensuring that it is correct and compliant.