[clang] Don't mark _ReadBarrier, _ReadWriteBarrier, _WriteBarrier deprecated
authorNico Weber <thakis@chromium.org>
Wed, 6 Oct 2021 14:30:14 +0000 (10:30 -0400)
committerNico Weber <thakis@chromium.org>
Wed, 6 Oct 2021 14:50:02 +0000 (10:50 -0400)
commitf9457f1f88b3e835fca8942b5272f3ecf26d4e98
treeb34c0f5aca4e37b473b85fe840649fa3b1f77145
parentff41fc07b12bd7bf3c8cd238824b16b1066fe5a0
[clang] Don't mark _ReadBarrier, _ReadWriteBarrier, _WriteBarrier deprecated

It's true that docs.microsoft.com says:

"""The _ReadBarrier, _WriteBarrier, and _ReadWriteBarrier compiler
intrinsics and the MemoryBarrier macro are all deprecated and should not
be used. For inter-thread communication, use mechanisms such as
atomic_thread_fence and std::atomic<T>, which are defined in the C++
Standard Library. For hardware access, use the /volatile:iso compiler
option together with the volatile keyword."""

And these attributes have been here since these builtins were added in
r192860.

However:

- cl.exe does not warn on them even with /Wall
- none of the replacements are useful for C code
- we don't add __attribute__((__deprecated__())) to any other
  declarations in intrin.h
- intrin0.h in the MSVC headers declares _ReadWriteBarrier() (but
  without the deprecation attribute), so you get inconsistent
  deprecation warnings depending on if you include intrin.h or intrin0.h

The motivation is that compiling sqlite.h with clang-cl produces a
deprecation warning with clang-cl for _ReadWriteBarrier(), but not with
cl.exe.

Differential Revision: https://reviews.llvm.org/D111232
clang/lib/Headers/intrin.h