Repository navigation
Update PAL libc math function introspection to be exact #35341
Description
Activity
@tannergooding I've set the milestone for this as 6.0.0, please feel free to change it if you disagree.
Reacted by Tanner Gooding@tannergooding do you have a plan to fix this for 6.0?
@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_atan2which 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."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 offloatanddoublebecome strictly the IEEE 754binary32andbinary64types;long doubleremains 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, andbinary128types as well as correspondingfloat16_t,float32_t,float64_t, andfloat128_ttypedefs 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:fastequivalent 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.- ghost locked as resolved and limited conversation to collaborators
on Aug 6, 2022
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.