EricWF added inline comments.
================
Comment at: include/__config:300
@@ -299,3 +299,3 @@
-#if !(__has_feature(cxx_exceptions))
+#if !(__has_feature(cxx_exceptions)) && !defined(_LIBCPP_NO_EXCEPTIONS)
#define _LIBCPP_NO_EXCEPTIONS
----------------
weimingz wrote:
> Is this change OK?
Yes.
================
Comment at: include/__mutex_base:43
@@ -42,3 +42,3 @@
_LIBCPP_INLINE_VISIBILITY
-#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+#ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR
constexpr mutex() _NOEXCEPT : __m_(PTHREAD_MUTEX_INITIALIZER) {}
----------------
weimingz wrote:
> EricWF wrote:
> > This is not OK. It's critical that mutex have a constexpr constructor that
> > it runs during the "Constant initialization" phase of static initialization.
> > Heres an example of the difference this makes: https://godbolt.org/g/3cvlMJ
> >
> > Also the constructor is specified as being constexpr in C++11. We can't
> > turn that off.
> >
> > If one particular pthread implementation is broken then we need a fix
> > targeted to only that implementation. However this seems like a pthread
> > bug and not a libc++ bug.
> The macro has an "#else" part. I'm not familiar with this, but it seems the
> constexpr an "optional feature".
>
>
>
So `_LIBCPP_HAS_NO_CONSTEXPR` checks for the presence of C++11 constexpr
semantics. In C++14 support for `constexpr` was greatly increased, allowing
many more expressions to be considered "constant expressions". The original
macro, and `_LIBCPP_HAS_NO_CXX14_CONSTXPR` check if a compiler has completely
implemented the C++11 or C++14 constexpr requirements respectively. In your
case `PTHREAD_MUTEX_INITIALIZER` is defined in such a way that it requires the
C++14 definition of `constexpr`.
http://reviews.llvm.org/D19344
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
