On 4/27/20 9:08 AM, Matthias Kretz wrote:
@item -ffinite-math-only
@opindex ffinite-math-only
-Allow optimizations for floating-point arithmetic that assume
-that arguments and results are not NaNs or +-Infs.
+Assume that floating-point types in the language do not have representations
for
+NaNs and +-Inf. Whether floating-point hardware supports and acts on NaNs and
++-Inf is not affected. The behavior of a program that uses a NaN or +-Inf
value
+as function argument, macro argument, or operand is undefined.
I'm chiming in here a bit late, but as documentation maintainer, I'm not
happy with the proposed new wording either, because it doesn't tell
users what this option is *for*. To expand on the existing language a
bit, its purpose is to allow GCC to compile floating-point arithmetic
expressions to hardware instructions that might not comply with the IEEE
754 requirements for handling of NaNs and Inf, and perhaps secondarily
to elide tests for NaNs and +-Inf in inlined code.
The proposed language "Assume that..." is ambiguous; who/what should
assume this, and why? I think it would be fine to say explicitly that
such cases have undefined behavior if you use this option, and also to
change "arguments" in the second line to "operands" to avoid confusion
with function or macro arguments, which isn't the point.
I'll defer to the subject-matter experts on the exact wording for
"undefined" and any other user-visible consequences of compiling with
this option.
-Sandra
