CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[David Chisnall]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130710/895e0af7/attachment.sig>