On 2021-08-07 14:32:32 +0200, Stefan Kanthak wrote: > Joseph Myers <jos...@codesourcery.com> wrote: > > On Fri, 6 Aug 2021, Stefan Kanthak wrote: > > PLEASE DON'T STRIP ATTRIBUTION LINES: I did not write the following paragraph! > > >> > I don't know what the standard says about NaNs in this case, I seem to > >> > remember that arithmetic instructions typically produce QNaN when one of > >> > the inputs is a NaN, whether signaling or not. > >> > >> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/trunc.html> > >> and its cousins as well as the C standard say > >> > >> | If x is NaN, a NaN shall be returned. > >> > >> That's why I mentioned that the code GCC generates also doesn't > >> quiet SNaNs. > > > > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling; > > I'll do so as soon as GCC drops support for all C dialects before C2x! > > Unless you use a time machine and fix the POSIX and ISO C standards > written in the past you CAN'T neglect all software written before C2x > modified sNaN handling that relies on the documented behaviour at the > time it was written.
Before C2x: This specification does not define the behavior of signaling NaNs.365) It generally uses the term NaN to denote quiet NaNs. 365) Since NaNs created by IEC 60559 operations are always quiet, quiet NaNs (along with infinities) are sufficient for closure of the arithmetic. (in Annex F). You can't create signaling NaNs with C operations, but you may get them when reading data from memory. So, IMHO, they should really be supported in practice, at least in some sense. I would expect that when a sNaN occurs as an input, it is handled either like a sNaN (see IEC 60559 / IEEE 754) or like a qNaN. Propagating the signaling status (forbidden in IEEE 754 for almost all operations) could be acceptable (this means that an implementation may ignore whether a NaN is quiet or signaling), but should be avoided. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
