[libc][math] should fmod(-NAN,-NAN) = +NAN?
#88772
Labels
Comments
lntue
pushed a commit
that referenced
this issue
May 6, 2024
… macros (#88816) Adds more FP test macros for the upcoming test adds for #61092 and the issues opened from it: #88768, #88769, #88770, #88771, #88772. Fix bug in `{EXPECT,ASSERT}_FP_EXCEPTION`. `EXPECT_FP_EXCEPTION(0)` seems to be used to test that an exception did not happen, but it always does `EXPECT_GE(... & 0, 0)` which never fails. Update and refactor tests that break after the above bug fix. An interesting way things broke after the above change is that `ForceRoundingMode` and `quick_get_round()` were raising the inexact exception, breaking a lot of the `atan*` tests. The changes for all files other than `FPMatcher.h` and `libc/test/src/math/smoke/RoundToIntegerTest.h` should have the same semantics as before. For `RoundToIntegerTest.h`, lines 56-58 before the changes do not always hold since this test is used for functions with different exception and errno behavior like `lrint` and `lround`. I've deleted those lines for now, but tests for those cases should be added for the different nearest int functions to account for this. Adding @nickdesaulniers for review.
|
cc @lntue |
|
so I don't think the standard requires any explicit nan, so any nan output would be sufficient. On the other hand, probably we shouldn't test for explicit nan value here, maybe testing whether the output is nan or not is more appropriate. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following up on #61092, the report seems to indicate that
fmod(-NAN,-NAN) = +NANis a problem.Is this wrong? I can't tell from 7.12.10.1.3 or F.10.7.1 what the behavior for two NaN arguments should be.
We seem to match glibc on this.
This behavior still happens and is already tested for, just a question of if we have the semantics correct?
Tagging @nickdesaulniers and @michaelrj-google.
The text was updated successfully, but these errors were encountered: