================
@@ -2707,27 +2707,31 @@ static bool checkFloatingPointResult(EvalInfo &Info,
const Expr *E,
if (Info.InConstantContext)
return true;
+ // The output result is exact and no exceptions are raised, so it is safe to
+ // perform compile-time evaluation.
+ if (St == APFloat::opOK)
+ return true;
+
FPOptions FPO = E->getFPFeaturesInEffect(Info.getLangOpts());
- if ((St & APFloat::opInexact) &&
- FPO.getRoundingMode() == llvm::RoundingMode::Dynamic) {
- // Inexact result means that it depends on rounding mode. If the requested
- // mode is dynamic, the evaluation cannot be made in compile time.
+
+ if (FPO.getRoundingMode() == llvm::RoundingMode::Dynamic) {
+ // Some floating point exception is raised, so the result might depend on
+ // rounding mode. If the requested mode is dynamic, the evaluation cannot
+ // be made in compile time.
----------------
hubert-reinterpretcast wrote:
I don't think dynamic rounding mode should suppress compile-time folding
because of floating point exceptions other than "inexact". For example, exact
infinities associated with division by zero should be fine. I agree, however,
that this issue is not new to this PR. Please add at least a FIXME.
https://github.com/llvm/llvm-project/pull/199808
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
