================
@@ -816,6 +816,11 @@ class FPOptions {
setAllowFPReassociate(LO.AllowFPReassoc);
setNoHonorNaNs(LO.NoHonorNaNs);
setNoHonorInfs(LO.NoHonorInfs);
+ // Ensure that if FiniteMathOnly is enabled, NoHonorNaNs and NoHonorInfs
are
+ // also enabled. This is because FiniteMathOnly mode assumes no NaNs or
Infs
+ // are present in computations.
+ if (!LO.NoHonorInfs || !LO.NoHonorInfs)
+ assert(!LO.FiniteMathOnly && "FiniteMathOnly implies NoHonorInfs");
----------------
jcranmer-intel wrote:
The way I see it, nnan and ninf collectively define four modes for math: full
types, no-nan, finite-math (nnan + ninf), and the extremely questionable (to me
at least) ninf-without-nnan. I don't think `FiniteMathOnly` as a concept
independent of the nnan/ninf flags makes much sense.
There is perhaps room for disagreement as to whether `__FINITE_MATH_ONLY__`
should be `nnan || ninf` or `nnan && ninf`; I lean towards && myself. Looking
at sourcegraph, there seems to be essentially three uses of these macros: two
to indicate that they don't care about min(NaN) results, and one to avoid using
fpclassify.
https://github.com/llvm/llvm-project/pull/97342
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
