This is an archive of the discontinued LLVM Phabricator instance.

[clang][ExprConst] Check float operation input for signaling NaNs
AbandonedPublic

Authored by tbaeder on Aug 3 2023, 11:28 PM.

Details

Reviewers
jcranmer-intel
aaron.ballman
sepavloff
Group Reviewers
Restricted Project
Summary

Split out from https://reviews.llvm.org/D156506.

Before adding this behavior to the new constexpr interpreter, I'd like to first see it in the current one.

This patch removes the checks for a NaN result of floating point operations and instead checks the input operands for signaling NaNs.

There are only three tests for the NaN-result check as far as I can see, so I added a few new ones.

Diff Detail

Event Timeline

tbaeder created this revision.Aug 3 2023, 11:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2023, 11:28 PM
tbaeder requested review of this revision.Aug 3 2023, 11:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2023, 11:28 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
sepavloff added inline comments.Sep 4 2023, 11:14 AM
clang/test/CXX/expr/expr.const/p2-0x.cpp
281–283

I don't think silent NaN origination is a right behavior. By design NaN is used to represent errors, so if a NaN appears, it may indicate a situation that needs user's attention. NaN propagation should be silent, an error has already appeared somewhere in the code.

I don't think it should be an error either. A user can use NaN to mark an error and treat it as if it were created by hardware. The code like:

const double PosNan = 1.0 / 0.0;
const double NegNaN = -1.0 /0.0;
const double NaN = 0.0 / 0.0;

is used enough often and there is no reason to prohibit it even in constant evaluations. So the best reaction could be a warning. Some users may suppress it, some promote to error.

This applies to other FP exceptions as well, but they were implemented previously.

tbaeder abandoned this revision.Oct 2 2023, 11:53 PM