[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