EricWF added a comment. In https://reviews.llvm.org/D32265#732649, @jfb wrote:
> In https://reviews.llvm.org/D32265#731710, @EricWF wrote: > > > In https://reviews.llvm.org/D32265#731709, @jfb wrote: > > > > > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's > > > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't > > > seem to have anything <https://godbolt.org/g/jQOxlu>? Presumably they'll > > > have to do *something*. > > > > > > The goal is to allow libc++ to implement`ATOMIC_<TYPE>_LOCK_FREE` on > > Windows using Clang. As you know libc++ currently uses the > > `__GCC_ATOMIC_FOO` macros, but those aren't available on Windows. > > > OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in > clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. > Would you all-out switch libc++ to use `__CLANG_*` then? `__CLANG` macros are fine on libc++'s end; So as long as they're not uncouth for Clang it should be OK. I would switch libc++ to do #ifdef __CLANG_ATOMIC_FOO # define ATOMIC_FOO __CLANG_ATOMIC_FOO # define ATOMIC_BAR __CLANG_ATOMIC_BAR #else # define ATOMIC_FOO __GCC_ATOMIC_FOO ... #endif > > >> Also AFAIK MSVC leaves the implementation of atomics up to the library, not >> the frontend. So W/E MSVC's STL does it's likely not sane or desirable. > > Wait what? How does that even work? This calls for a Twitter ping of Billy! https://reviews.llvm.org/D32265 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
