================
@@ -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");
----------------
AaronBallman wrote:
> There is quite a bit of LIT tests that have that "logic bug" then. They are
> using -Xclang -menable-no-infs -Xclang -menable-no-nan without the
> -ffinite-math-only option.
I didn't mean the logic bug was on the user end; I meant that our internal
state has the logic bug because `!FiniteMathOnly` implies that infinities are
supported and so it logically conflicts with `!HonorInfs`.
> Getting rid of FiniteMathOnly is fine by me.
FiniteMathOnly = !HonorINFs && !HonorNaNs which would mean -menable-no-infs
-menable-non-nans. I would think using one or the other of these options could
still mean that input values may be either INF or NAN or we can produce them,
in which case we wouldn't be in finite math mode.
I can see the logic there and I think that's defensible, but because
`FiniteMathOnly` determines the value `__FINITE_MATH_ONLY__` expands to, we
should probably see how that flag is being used in the wild to see whether
folks expect it to be `1` or `0` when infinity is enabled but NAN is disabled
(for example).
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
