[RFC] Clarify -ffinite-math-only documentation

Sandra Loosemore sandra@codesourcery.com
Tue Apr 28 19:35:33 GMT 2020


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


More information about the Gcc-patches mailing list