[PATCH] D32265: Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via Phabricator via cfe-commits]

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