[clang] [NFC] Add assertion to ensure FiniteMathOnly is in sync with HonorINFs and HonorNANs. (PR #97342)
Joshua Cranmer via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 3 13:47:10 PDT 2024
================
@@ -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
More information about the cfe-commits
mailing list