[all-commits] [llvm/llvm-project] f9457f: [clang] Don't mark _ReadBarrier, _ReadWriteBarrier...

[Nico Weber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f9457f1f88b3e835fca8942b5272f3ecf26d4e98
      https://github.com/llvm/llvm-project/commit/f9457f1f88b3e835fca8942b5272f3ecf26d4e98
  Author: Nico Weber <thakis at chromium.org>
  Date:   2021-10-06 (Wed, 06 Oct 2021)

  Changed paths:
    M clang/lib/Headers/intrin.h

  Log Message:
  -----------
  [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