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.
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:
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.