jfb added inline comments. ================ Comment at: include/atomic:859 @@ +858,3 @@ +template <> _LIBCPP_CONSTEXPR bool __libcpp_always_lock_free<char32_t> = 2 == ATOMIC_CHAR32_T_LOCK_FREE; +template <> _LIBCPP_CONSTEXPR bool __libcpp_always_lock_free<wchar_t> = 2 == ATOMIC_WCHAR_T_LOCK_FREE; +template <> _LIBCPP_CONSTEXPR bool __libcpp_always_lock_free<short> = 2 == ATOMIC_SHORT_LOCK_FREE; ---------------- bcraig wrote: > Do we need to support configurations were wchar_t is a typedef to an integer > type, or is that an abomination too painful to deal with? > > I have no idea if the rest of libcxx attempts to deal with wchar_t typedefs. Do you have examples of such platforms? The standard is pretty clear that they're wrong:
> [basic.fundamental] > > Type `wchar_t` is a distinct type whose values can represent distinct codes > for all members of the largest extended character set specified among the > supported locales. Type `wchar_t` shall have the same size, signedness, and > alignment requirements as one of the other integral types, called its > *underlying type*. I'll defer to @mclow.lists on whether we can about such implementations or not. http://reviews.llvm.org/D17951 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
