On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote:
> Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz <m.kr...@gsi.de> wrote:
> >> Hi,
> >>
> >> This documentation change clarifies the effect of -ffinite-math-only.
> >> With the current documentation, it is unclear what the presence of NaN
> >> and Inf representations means if (arithmetic) operations on such values
> >> are unspecified and even classification functions like isnan are
> >> unreliable. If the hardware thinks a certain bit pattern is a NaN, but
> >> the software assumes a NaN value cannot ever exist, it is questionable
> >> whether, from a language viewpoint, a representation for NaNs really
> >> exists. Because, a NaN is defined by its behavior. This change also
> >> clarifies that isnan(nan) returning false is fine.
> >>
> >> This relates to PR84949.
> >>
> >> * doc/invoke.texi: Clarify the effects of -ffinite-math-only.
> >>
> >> ---
> >>
> >> gcc/doc/invoke.texi | 6 ++++--
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> index a37a2ee9c19..9e76ab057a9 100644
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
> >>
> >> @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.
> >
> > Minor nit here - I'd avoid the 'undefined' word which has bad connotation
> > and use 'unspecified'. Maybe we can even use ISO C language specification
> > terms but I'm not sure which one is most appropriate here.
I'm an ISO C++ person, and unspecified sounds too reliable to me:
https://wg21.link/intro.defs#defns.unspecified.
> > Curiously __builtin_nan ("nan") still gets you a NaN representation
> > but isnan(__builtin_nan("nan")) is resolved to false.
Right, that's because only the hardware thinks __builtin_nan ("nan") is a NaN
representation. With -ffinite-math-only, the double data type in C/C++ can
either hold a finite real value, or an invalid value (i.e. a value that the
optimizer unconditionally excludes as a possible value for any object of
floating-point type). FWIW, with -ffinite-math-only, ubsan should flag
isnan(__builtin_nan("nan")) or any f(constexpr nan).
With the above documentation change, it is clear that with https://wg21.link/
P1841 std::numbers::quiet_NaN<float> would be ill-formed under -ffinite-math-
only. Without the documentation change, it can be argued either way.
There's another interesting observation resulting from the above: double and
double under -ffinite-math-only are different types. Any function call from
one world to the other is dangerous. Inline functions translated in different
TUs compiled with different math flags violate the ODR. But that's all the
more reason to have a very precise documentation/understanding of what
-ffinite-math-only does. Because this gotcha is already the status quo.
> Yeah, for that and other reasons, I think it would be good to avoid
> giving the impression that -ffinite-math-only can be relied on to make
> the assumption above. Wouldn't it be more accurate to say that the
> compiler is allowed to make the assumption, at any point that it seems
> convenient?
I think undefined behavior does what you're asking for while unspecified
behavior does what you want to avoid. I.e. its an undocumented behavior, but
it can be relied on with a given implementation (compiler).
-Matthias
--
──────────────────────────────┬────────────────────────────────────────────
Dr. Matthias Kretz │ SDE — Software Development for Experiments
Senior Software Engineer, │ 📞 +49 6159 713084
SIMD Expert, │ 📧 m.kr...@gsi.de
ISO C++ Committee Member │ 🔗 mattkretz.github.io
──────────────────────────────┴────────────────────────────────────────────
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de
Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung:
Professor Dr. Paolo Giubellino, Jörg Blaurock
Chairman of the Supervisory Board / Vorsitzender des GSI-Aufsichtsrats:
State Secretary / Staatssekretär Dr. Georg Schütte
