aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineBasicBlock.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2020-10-01 13:45:05 -0400
committerSanjay Patel <spatel@rotateright.com>2020-10-01 13:46:45 -0400
commit686eb0d8ded9159b090c3ef7b33a422e1f05166e (patch)
treea89aaf99e7bf46430c22eec87d41fd6f3f307820 /llvm/lib/CodeGen/MachineBasicBlock.cpp
parent114e964dce9f18e8f3c25a3a4136e59ead9ae50c (diff)
downloadllvm-686eb0d8ded9159b090c3ef7b33a422e1f05166e.zip
llvm-686eb0d8ded9159b090c3ef7b33a422e1f05166e.tar.gz
llvm-686eb0d8ded9159b090c3ef7b33a422e1f05166e.tar.bz2
[AST] do not error on APFloat invalidOp in default mode
If FP exceptions are ignored, we should not error out of compilation just because APFloat indicated an exception. This is required as a preliminary step for D88238 which changes APFloat behavior for signaling NaN convert() to set the opInvalidOp exception status. Currently, there is no way to trigger this error because convert() never sets opInvalidOp. FP binops that set opInvalidOp also create a NaN, so the path to checkFloatingPointResult() is blocked by a different diagnostic: // [expr.pre]p4: // If during the evaluation of an expression, the result is not // mathematically defined [...], the behavior is undefined. // FIXME: C++ rules require us to not conform to IEEE 754 here. if (LHS.isNaN()) { Info.CCEDiag(E, diag::note_constexpr_float_arithmetic) << LHS.isNaN(); return Info.noteUndefinedBehavior(); } return checkFloatingPointResult(Info, E, St); Differential Revision: https://reviews.llvm.org/D88664
Diffstat (limited to 'llvm/lib/CodeGen/MachineBasicBlock.cpp')
0 files changed, 0 insertions, 0 deletions