jfb added a comment. 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? > 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
