Skip to content
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

fmt::isnan triggers floating-point exception for NaN values #3948

Closed
alexdewar opened this issue May 1, 2024 · 4 comments · Fixed by #3951
Closed

fmt::isnan triggers floating-point exception for NaN values #3948

alexdewar opened this issue May 1, 2024 · 4 comments · Fixed by #3951

Comments

@alexdewar
Copy link
Contributor

alexdewar commented May 1, 2024

Note: floating-point exceptions are not the same as C++ exceptions! See: https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Control-Functions.html

Commit ef54f9a changed the implementation of fmt::isnan from:

template <typename T> constexpr bool isnan(T value) {
  return value != value;  // std::isnan doesn't support __float128.
}

To:

template <typename T> constexpr bool isnan(T value) {
  return !(value >= value);  // std::isnan doesn't support __float128.
}

The commit description says that this was done to suppress -Wfloat-equal warnings. The problem is that these two implementations are subtly different: while they both return the same value, the newer implementation also sets a floating-point exception flag. The reason is that while for IEEE-754 floating-point numbers the operation NaN != NaN is well defined and will always return true, NaN >= NaN is technically an invalid operation, hence why the exception flag is set (at least this is my non-expert understanding).

This has been causing headaches for a project I'm working on because I wanted to trace where floating-point exceptions were emanating from in my program (using the GNU-specific feenableexcept function), but fmt::isnan will raise a spurious exception every time a NaN is passed in. Changing the code to use value != value instead fixes things.

I guess there are different ways to fix this, but maybe you could just return to using value != value and find another way to suppress the warning (e.g. with a comment or a compiler argument)?

@vitaut
Copy link
Contributor

vitaut commented May 1, 2024

Thanks for reporting. Could you by any chance provide a godbolt repro that demonstrates the issue?

@alexdewar
Copy link
Contributor Author

Sure. Here you go: https://godbolt.org/z/Pvc43M46n

@vitaut
Copy link
Contributor

vitaut commented May 2, 2024

I think reverting to != makes sense. Could you submit a PR to do this and add a new test case that checks FP exceptions?

@alexdewar
Copy link
Contributor Author

Sure!

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

Successfully merging a pull request may close this issue.

2 participants