Skip to content

[libc][math] should asin functions set errno == ERANGE on underflow? #88770

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Flandini opened this issue Apr 15, 2024 · 2 comments
Open

[libc][math] should asin functions set errno == ERANGE on underflow? #88770

Flandini opened this issue Apr 15, 2024 · 2 comments
Labels

Comments

@Flandini
Copy link
Contributor

Following up on #61092.

asinf is setting FE_UNDERFLOW in these cases, but I don't think it sets errno == ERANGE in all cases for all asin implementations. It is implementation defined if errno is set to ERANGE in this case.

Thoughts @michaelrj-google @nickdesaulniers?

@github-actions github-actions bot added the libc label Apr 15, 2024
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.
@nickdesaulniers
Copy link
Member

cc @lntue

@lntue
Copy link
Contributor

lntue commented Oct 10, 2024

I think we should.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants