Date: Wed, 10 Jul 2013 18:33:15 +0200 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: David Chisnall <theraven@FreeBSD.org> 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: <20130710183315.725dfde0@thor.walstatt.dyndns.org> In-Reply-To: <CD51F125-AE9E-4461-916D-CF583002B47D@FreeBSD.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <CD51F125-AE9E-4461-916D-CF583002B47D@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Wed, 10 Jul 2013 15:22:58 +0100
David Chisnall <theraven@FreeBSD.org> wrote:
> Hi,
>
> On 10 Jul 2013, at 14:58, "O. Hartmann" <ohartman@zedat.fu-berlin.de>
> wrote:
>
> >
> > 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:
> >
> > [...]
> > ../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) {}
> > [...]
> >
> > 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=c++11 -stdlib=libc++.
> >
> > 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.
> >
> > Is this a bug in FreeBSD's implementation of libc++? Or am I doing
> > something wrong?
> >
> > I'm new to C++/C++11.
> >
> >
> > 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) == sizeof (float)) ? __isnanf(x) \
> : (sizeof (x) == 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
>
Hi David,
thanks for the fast response.
The code I was told to check with is this:
#include <iostream>
#include <typeinfo>
#include <cmath>
int
main(void)
{
std::cout << typeid(isnan(1.0)).name() << "\n";
}
If I compile it with
c++ -o testme -std=c++11 -stdlib=libc++ source.cc
and run the binary, the result is "i" which I interpret as "INT".
My OS is at
FreeBSD 10.0-CURRENT #4 r253138: Wed Jul 10 09:52:16 CEST 2013
Oliver
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iQEcBAEBAgAGBQJR3YzQAAoJEOgBcD7A/5N8ipIH/RlVZV2UXHNWv/F1Zx7kkAJK
7JFbay3QwLnoLOScXsQB9EoaXbh4ha91P1krgAccg39/esWXeBwdGRkcPe03oYkU
BHHfN2RKTIERO71daPL7Y5nan3z9IYY8q0KlnMU7Xf5t/B/CMYXKyASv53s0eyNU
tcblIzHHmdVwT1AfEszhBr70umS6SyIqUqlot5L3uqJF+2CTDeHjw7hj8shUN60W
Jd/kC8F2zcCEC8UjwEDRDL8556e5NOIuNown6+VOhBCSAv2fiiYQe4hKgJuEfCPx
hOALmY6K0uxcF/SlLfxX3fd2QzaAs8ShCiNvvi1Vz+nppCV8ytNRiwf1+xqVtLQ=
=vG0c
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130710183315.725dfde0>