================
@@ -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.
Info.FFDiag(E, diag::note_constexpr_dynamic_rounding);
return false;
}
- if ((St != APFloat::opOK) &&
- (FPO.getRoundingMode() == llvm::RoundingMode::Dynamic ||
- FPO.getExceptionMode() != LangOptions::FPE_Ignore ||
- FPO.getAllowFEnvAccess())) {
- Info.FFDiag(E, diag::note_constexpr_float_arithmetic_strict);
- return false;
- }
+ // No fenv access and floating point exceptions are ignored, so it is safe to
+ // to perform compile-time evaluation.
----------------
hubert-reinterpretcast wrote:
As we are expanding to `math.h` functions, this logic is not longer sound.
`-fmath-errno` needs to be respected when we are checking the result from such
a function but, otherwise, it should be ignored.
https://github.com/llvm/llvm-project/pull/199808
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits