This does not handle the builtin functions yet, since I'm not sure if I should check for all nans or only signaling ones yet.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This does not handle the builtin functions yet, since I'm not sure if I should check for all nans or only signaling ones yet.
I think it's only signaling ones, but CC @jcranmer-intel for a better-informed answer.
The changes here LGTM though.
You definitely don't want these rules to apply to all qNaNs. It's when an input operand is an sNaN for many operations. Note that the result of an operation with an sNaN as input (and FP result type) is a qNaN output, and the only times that you get an sNaN output are the times when you never signal (I think), so checking the result type is incorrect.
clang/lib/AST/Interp/Interp.cpp | ||
---|---|---|
535–540 | A further note is that sNaNs signal FE_INVALID when used, so sNaN should generally fall into this if statement in particular. |
clang/lib/AST/Interp/Interp.cpp | ||
---|---|---|
504 | @jcranmer-intel Doesn't this comment (which I've coped from ExprConstant.cpp) contradict what you said about not checking the result? |
clang/lib/AST/Interp/Interp.cpp | ||
---|---|---|
504 | Immediately following that in the specification is this:
The current C++ specification is rather clear about its unclarity on floating-point. Also note that IEEE 754 defines floating-point data as consisting of {-inf, ..., -0} union {+0, ..., +inf} union {NaN}. So NaN is arguable to be a well-defined mathematical result, if you consider that floating-point types don't model real numbers but an approximation of real numbers (just as unsigned integers model not integers but integers mod 2^N). |
I thought this review wasn't clear at all on what's supposed to happen but since https://reviews.llvm.org/D157072 is going nowhere, I'll just push this one in the next few days.
@jcranmer-intel Doesn't this comment (which I've coped from ExprConstant.cpp) contradict what you said about not checking the result?