From owner-freebsd-toolchain@FreeBSD.ORG Thu Jul 11 08:47:49 2013 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C180B31; Thu, 11 Jul 2013 08:47:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id F04E31B5A; Thu, 11 Jul 2013 08:47:48 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r6B8kLGo001311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Jul 2013 08:46:23 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity From: David Chisnall In-Reply-To: <20130711130043.R920@besplex.bde.org> Date: Thu, 11 Jul 2013 09:46:17 +0100 Message-Id: References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1503) Cc: Garrett Wollman , Tijl Coosemans , FreeBSD CURRENT , freebsd-standards@FreeBSD.org, freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:47:49 -0000 --Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bruce, You're joining in this discussion starting in the middle, so you = probably missed the earlier explanation. On 11 Jul 2013, at 05:21, Bruce Evans wrote: > I don't see how any conforming program can access the isnan() function > directly. It is just as protected as __isnan() would be. (isnan)() > gives the function (the function prototype uses this), but conforming > programs can't do that since the function might not exist. Maybe some > non-conforming program like autoconfig reads or libm.a and > creates a bug for C++. The cmath header defines a template function isnan that invokes the = isnan macro, but then undefines the isnan macro. This causes a problem = because when someone does something along the lines of using namespace = std then they end up with two functions called isnan and the compiler = gets to pick the one to use. Unfortunately, std::isnan() returns a = bool, whereas isnan() returns an int. =20 The C++ headers are not required to be conforming C code, because they = are not C, and our math.h causes namespace pollution in C++ when = included from . > The FreeBSD isnan() implementation would be broken by removing the > isnan() function from libm.a or ifdefing it in . Changing the > function to __isnan() would cause compatibility problems. The = function > is intentionally named isnan() to reduce compatibility problems. On OS X this is avoided because their isnan() macro expands to call one = of the __-prefixed inline functions (which adopt your suggestion of = being implemented as x !=3D x, for all types). I am not sure that this = is required for standards conformance, but it is certainly cleaner. = Your statement that having the function not called isnan() causes = compatibility problems is demonstrably false, as neither OS X nor glibc = has a function called isnan() and, unlike us, they do not experience = problems with this macro. =20 It would also be nice to implement these macros using _Generic when = compiling in C11 mode, as it will allow the compiler to produce more = helpful warning messages. I would propose this implementation: #if __has_builtin(__builtin_isnan) #define isnan(x) __builtin_isnan(x) #else static __inline int __isnanf(float __x) { return (__x !=3D __x); } static __inline int __isnand(double __x) { return (__x !=3D __x); } static __inline int __isnanl(long double __x) { return (__x !=3D __x); } #if __STDC_VERSION__ >=3D 201112L #define isnan(x) _Generic((x), \ float: __isnanf(x), \ double: __isnand(x), \ long double: __isnanl(x)) #else #define isnan(x) \ ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x) \ : (sizeof (x) =3D=3D sizeof (double)) ? __isnand(x) \ : __isnanl(x)) #endif #endif For a trivial example of why this is an improvement in terms of error = reporting, consider this trivial piece of code: int is(int x) { return isnan(x); } With our current implementation, this compiles and links without any = warnings, although it will have somewhat interesting results at run = time. With the __builtin_isnan() version, clang reports this error: isnan.c:35:15: error: floating point classification requires argument of floating point type (passed in 'int') return isnan(x); ^ (and then some more about the macro expansion) With the C11 version, it reports this error: isnan.c:35:15: error: controlling expression type 'int' not compatible = with any generic association type return isnan(x); ^ David --Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51 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 iQIcBAEBAgAGBQJR3nDZAAoJEKx65DEEsqIdT0UP/R3/DJeYYumScK0sTI0u0f/K zr03X2Nn8rHa4xk8avxANTaYYK8QfutKvViv11G1JH/gTGMNh8LxxdoRhsVx4bOe rAjYY+NDplfLqKTBva+zf25FiQNOn08NnOZDd9l0ApyAK1u2J2dp7Q9yqZbRU7Kj bACBptR3dREJzSZgIbQcJ5WE3BDsBztW0Az3/WcyDtmILmZ8psVLs+R39qe4yjeV NxNQRDJuJmccxi8Jx6sjQaUrXVLZ4VWc0Cbr7+0SasHY1avtqoHr6H5pt3ltUtfF Ld0wQHG8MUuuqZd9j1tQDHSKWmjeDQdOwu8IjEbGP/IXjJI/lK93+K07qMgQPp5G DJzPoSxJEKTVudNVBuv8sA6iToWMli9ZI/h4YL0Lc0G5vOwLbPHcX1ctEb+g118z 676x26Xdr/vawe0rddCUW2z+CVHj7q1eKY37Za9xVlmchUYWMMzqE8m9MdlQGvmi y60IDPDcwCiIoZZQ2VbE+wqrgWevEi0nASFttrgqrS7HEBy/rszm8Cdy1wZqUKSe xi2CwevaMWSfTc9MIwGId5y89UjQ5bSzAPBFWonFZkd/KDN6rRQ1LZvyVrMuZMlX q/6/2ksNXFHzonOw66/913m+JjYYEaSjmndL0w30qN5HKdNw8C6d+Y9EMrQRMK1A cjNdMjwrwk2pdBNsVo1d =FIry -----END PGP SIGNATURE----- --Apple-Mail=_B9A0D356-39FE-4BC5-B2BB-1563285CBA51--