================
@@ -1871,6 +1874,37 @@ for more details.
- The option ``-fno-rounding-math`` allows the compiler to assume that the
rounding mode is set to ``FE_TONEAREST``. This is the default.
- The option ``-frounding-math`` forces the compiler to honor the
dynamically-set rounding mode. This prevents optimizations which might affect
results if the rounding mode changes or is different from the default; for
example, it prevents floating-point operations from being reordered across most
calls and prevents constant-folding when the result is not exactly
representable.
+.. option:: -f[no-]signaling-nans
+
+ Informs the compiler whether signaling NaNs behave according to IEEE 754.
+
+ IEEE 754 defines signaling NaNs (sNaNs) as a subset of Not-a-Numbers (NaNs),
+ that possess the following properties:
+
+ * Floating-point operations in which an sNaN is an operand, raise the
+ ``Invalid`` exception.
+ * Floating-point operations do not produce sNaNs; only a quiet NaN can be a
+ result.
+
+ Some target architectures do not support sNaNs. On such a target, the
+ behavior of an sNaN is same as that of a quiet NaN: it can appear as a
+ result, and the "Invalid" exception is not raised when it is an operand in
+ an operation.
+
+ The option ``-fsignaling-nans`` specifies IEEE 754 compliant behavior for
+ signaling NaNs. It has no effect if the target architecture does not
+ implement IEEE 754 signaling NaN behavior. This option causes the
+ preprocessor macro ``__SUPPORT_SNAN__`` to be defined.
+
+ The option ``-fno-signaling-nans`` specifies that signaling NaNs are treated
+ in the same way as quiet NaNs. This is the only option allowed if the target
+ architecture does not implement signaling NaNs according to IEEE-754. On the
+ supporting architectures, it can enable additional optimization
opportunities.
+
+ If more than one option is specified, the last one takes effect. If none is
+ specified, the compiler assumes ``-fno-signaling-nans``, unless the code is
+ compiled as strictfp functions, in which case ``-fsignaling-nans`` is
assumed.
----------------
spavloff wrote:
> Is this implying this has any effect in non-strictfp functions?
No, such restriction cannot be expressed if we don't have user-level
explanation for `strictfp`.
> strictfp is also the IR name, it doesn't belong in the clang manual
Exactly. The existing behavior cannot be preserved. Instead, we need to require
explicit use of `-fsignaling-nans` whenever sNaN semantics is required.
https://github.com/llvm/llvm-project/pull/193055
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
