[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190224210438.6980bd87@inria.fr>
Date: Sun, 24 Feb 2019 21:04:38 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: FE Exception triggered by comparison
Hello,
On Sun, 24 Feb 2019 20:25:11 +0100 Szabolcs Nagy <nsz@...t70.net> wrote:
> * Damian McGuckin <damianm@....com.au> [2019-02-25 00:28:20 +1100]:
> > What comparison of FP numbers trigger invalid operation exceptions?
> >
> > Does a comparison like
> >
> > if (x != x)
> > {
> > /* get to here if x == NaN *
> > }
> >
> > which tests for a NaN cause an invalid operation if given an sNaN?
>
> iso c does not say much about sNaN: a conforming implementation
> does not have to support sNaN (it is usually treated as qNaN,
> with unspecified signaling behaviour and you need special
> compiler options to ensure sNaN breaking transformations are
> not done if you want to rely on sNaN signals)
>
> with c99 annex F, c == and != operators are mapped to ieee 754
> compareQuiet{Not}Equal, which is non-signaling with qNaN inputs
> but signals invalid with sNaN inputs, so in practice sNaN != sNaN
> will signal in c.
>
> > Even reading the standard numerous times and I am not any wiser.
>
> i think it's better to look at the ieee 754 spec instead
> of the c spec, drafts are at http://754r.ucbtest.org/drafts/
>
> annex F.3 describes how c is mapped to ieee 754 (iec 60559
> is supposed to be very close to ieee 754).
>
> ts 18661-* provides more detailed description of the mapping
> to ieee 754-2008 (it will likely be part of c2x and it is a
> bit more strict than what iso c currently allows).
Yes, we are currently integrating parts 1 and 2 of this TS into the
standard. Usually you should be able to see a first version of that in
a few weeks in the pre-London mailing.
For the moment they are integrated "as such" that is with "WANT"
macros that make these "new" interfaces optional. Further in the
process I hope that we will be able to do a bit more:
- Remove this "optionality" from the numbered clauses and make all
interfaces mandatory.
- Some naming changes while these are not too fixed in peoples
minds. Only very few identifiers in <math.h> are reserved for
future use, so adding new interfaces will necessarily step on
someones shoes.
- Add some version macros for the different header files, such that
applications and implementors have better chances to adapt during
the time of transition.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
