Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jul 2013 15:22:58 +0100
From:      David Chisnall <theraven@FreeBSD.org>
To:        "O. Hartmann" <ohartman@zedat.fu-berlin.de>
Cc:        FreeBSD CURRENT <freebsd-current@FreeBSD.org>, freebsd-toolchain@FreeBSD.org
Subject:   Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Message-ID:  <CD51F125-AE9E-4461-916D-CF583002B47D@FreeBSD.org>
In-Reply-To: <20130710155809.0f589c22@thor.walstatt.dyndns.org>
References:  <20130710155809.0f589c22@thor.walstatt.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 10 Jul 2013, at 14:58, "O. Hartmann" <ohartman@zedat.fu-berlin.de> =
wrote:

>=20
> Whe I try to compile the sources of a port in spe (devel/pocl), which
> is now out as RC6, I receive this error shown below:
>=20
> [...]
> ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> conversion from 'int' to 'boolvec_t' (aka 'boolvec<real_t, size>') is
> ambiguous boolvec_t isinf() const { return std::isinf(v); }
> ^~~~~~~~~~~~~ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
> candidate constructor boolvec(bvector_t x): v(x) {}
>    ^
> ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
> constructor boolvec(bool a): v(a) {}
> [...]
>=20
> Compilation is performed on the most recent CURRENT with CLANG 3.3 and
> devel/llvm (which is obviously stuck with 3.2 for now) and option
> switches -std=3Dc++11 -stdlib=3Dlibc++.
>=20
> As I was told, in standard C++11, isnan(), isinf() and fellows now
> should return "bool", not int as this seems obviously the case as the
> error documents and I was able to check with a small program.
>=20
> Is this a bug in FreeBSD's implementation of libc++? Or am I doing
> something wrong?
>=20
> I'm new to C++/C++11.
>=20
>=20
> Some advice or explanation could be helpful.

I believe that this is also causing some failures in the libc++ test =
suite and is due to some interaction between our headers and the libc++ =
headers, but I don't see where it is.

Our isnan implementation is a really ugly macro that looks like this:

#define>isnan(x)					\
    ((sizeof (x) =3D=3D sizeof (float)) ? __isnanf(x)	\
    : (sizeof (x) =3D=3D sizeof (double)) ? isnan(x)	\
    : __isnanl(x))


The definition in the libc++ cmath header is:

#ifdef isnan

template <class _A1>
_LIBCPP_ALWAYS_INLINE
bool
__libcpp_isnan(_A1 __x) _NOEXCEPT
{
    return isnan(__x);
}

#undef isnan

This should work correctly.

However...

I wonder if you are including math.h instead of <cmath>?  That would =
show the result that you appear to be seeing, which looks like the =
result of using the isnan() macro rather than the isnan() function.  If =
you have included <cmath> then the isnan() macro will have been defined.

David


--Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995
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

iQIcBAEBAgAGBQJR3W5DAAoJEKx65DEEsqIdpMcQAJFPGPHktElFQHRQ0VMRFTqI
qhoWL0A0W2UBKaYcXX9OTzRjoE3jVYRKsj9/3ZDJuZ2z02o5lHa1Wir8dfGpTK05
MSoB30IWoHNP5dr6x/EiIB6xCuGckvSXPuJ6Jpmns2c7UP907pHPlInrtCUtqqOL
jKf5IsURUn7CxGAWLmDAa+RY1B4NjmWiIpmxrrSHNGk7NX4IYPRjKb1T2esrxUqi
gVY2QhGzwupaVjUqrPxaSLmwim0LWgwLSrk8oyMy/BXA/s0S33MJTqc3BnEMV6ZZ
xpCD8ct9ELGRfGXUyvu2n8Te9Sp8ZXKGnVhu8IAopqkI+0GsoNPNr8ogEiDZZCrk
II6CQ/5tCnvDdcETW2Gwe60WZtq5qTyqyYns4AM1+dam4TcQTLoVyD4eVFSlIhdP
AOLgNBOieNg0lkKzDHbmR7HgKD90sMTT6kC3sCFmqOc57kbOOuYDpsP/UQFeNrhH
4oG2tRH8OUiu9Kuz79Y5ollCVeDawhnvWdHFv8mVTRTR0GtuKQttwmKoevHM/csG
pWiDxuqXa+vsf55cCnMRLM/dWPd3iJnS9pNMgQpO6SstWTUJuBJb75Qhuo/S5+Tl
OABSctzzRwoAzx2zb+NPgms3jOjeTdHuZNaYY5ttxEDfz6qQVZT73eiImgdIsm+y
CnJF7AollbHrh49w/dsb
=8y6+
-----END PGP SIGNATURE-----

--Apple-Mail=_207DEF59-C596-4AAA-9DCB-2EC9FC626995--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CD51F125-AE9E-4461-916D-CF583002B47D>