On Tue, Apr 28, 2020 at 10:54 PM Sandra Loosemore <san...@codesourcery.com> wrote: > > 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*.
Good point. The original text at least had "Allow optimizations ...". Maybe the new text (if we can agree on it) could be amended with "This allows optimizations like transforming x * 0 to 0 which would be incorrect if x is a NaN under strict IEEE rules by assuming that x cannot be NaN." ? > 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
