Hi, On 10 Jul 2013, at 14:58, "O. Hartmann" <ohartman_at_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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC