Date: Mon, 29 Jul 2013 13:56:16 +0100 From: David Chisnall <theraven@FreeBSD.org> To: David Schultz <das@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r253215 - head/lib/msun/src Message-ID: <00F2B647-8D25-45FB-B852-5214AC27AD26@FreeBSD.org> In-Reply-To: <20130729070517.GA3192@zim.MIT.EDU> References: <201307111741.r6BHf5gQ060844@svn.freebsd.org> <20130729070517.GA3192@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_3C6D5381-7307-4D22-BA89-D60C029038E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 29 Jul 2013, at 08:05, David Schultz <das@FreeBSD.ORG> wrote:
> On Thu, Jul 11, 2013, David Chisnall wrote:
>> +static __inline int
>> +__inline_isnan(double __x)
>> +{
>> +
>> + return (__x !=3D __x);
>> +}
>> +
>> +static __inline int
>> +__inline_isnanf(float __x)
>> +{
>> +
>> + return (__x !=3D __x);
>> +}
>> +
>> +static __inline int
>> +__inline_isnanl(long double __x)
>> +{
>> +
>> + return (__x !=3D __x);
>> +}
>=20
> This has already been covered at greater length, but I believe
> this part is incorrect. Relational operators can raise an invalid
> exception when one of the arguments is a NaN -- even a quiet NaN.
> Raising an exception is optional in C99 (7.12.14) and required in
> IEEE-754... in practice, it tends to be platform- and compiler-
> specific.
>=20
> That is the whole reason the is* macros are defined by the
> standard in the first place, and also why we didn't use the
> trivial implementation above. The is* macros are required to not
> raise an exception.
What would you suggest replacing them with? Note that currently LLVM iR =
doesn't provide any way of distinguishing the !=3D comparison from =
something that is guaranteed not to raise an exception. I don't know =
how this works in GIMPLE, althouhg I'd imagine that, since gcc has a =
working Fortran front end, there is some better support for it.
> P.S. It would be great if clang implemented the FENV_ACCESS pragma
> and provided an intrinsic that produced a fast inline isnan() when
> the pragma is off, and the full, correct one when the pragma is on.
I almost agree, but C is a really terrible language for mathematical =
work and I'd prefer that people just used Fortran instead of trying to =
force C to be Fortran. In particular, take a look in the C11 spec for =
the semantics of this:
_Atomic(double) x =3D ...;
x +=3D 1;
It's quite astonishingly horrible. We don't implement it correctly in =
clang, and I hope never to have to. =20
David
--Apple-Mail=_3C6D5381-7307-4D22-BA89-D60C029038E4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJR9mZwAAoJEKx65DEEsqIdTlwQAM+U1r4cObj7aUCDAUcmf9zk
qxr6CvWiaEljzmu+juaJ39Lc2acHoRAmtZuL7qria99EuM2P/efSEOe2fdBF48C/
wMmj9+P1CWrLp6YNsg3zcC4X6D4OgYQ7XftwHwvIbKDUj4UxYreLiE6KXSBibtDJ
CD+HlT6GsXd2XopmsgkemgXufp20O18UR4WixR4LxXiNYa4KoIrXSIJdlXpIVKTY
Z9W4AaPMkfou8+L8bH9mtMNTBjwXWDLoNQFzWUyh08zcHLvmp6czOsv/3quUSJMB
mq6l6e3HrWhvimWF4QXx1kl/+B8Z0b2WPwXag6byXqm+SunxYlLwI2gL0efiR8Xu
blX+H2N1hFPljRPJH8+Nfv+ZIuYEjrVULSgkz18FRXpA98IjsWCPyX5uzZ5jZHAq
vcGXgBcSJ9asxKbf2Hsb6RYDQ18gHFZAxI73oBRjiu2lwtBVqFqr+h5SXfGyZE2E
rMA3ne5CiV7pT6WemhZSGZb1IcChaF/La6JyYbsorEuDwrc/Dwuy660T9xuh6MQk
fS4CgmckHKz1A0RC5kdRCvU272dOlzXrh5Ch7twZIP+OGPAtZf00KEb7HnQ7n+EU
SW0x4+Ri7R9KghjfaXIF82HeX1bLMHX3t0RcCOvkaJDrvYgVs3v0pFZj07yh1zwO
vZXO/HmsK4N8iuuIiDvP
=8mBa
-----END PGP SIGNATURE-----
--Apple-Mail=_3C6D5381-7307-4D22-BA89-D60C029038E4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00F2B647-8D25-45FB-B852-5214AC27AD26>