diff options
| author | Nico Weber <thakis@chromium.org> | 2021-10-06 10:30:14 -0400 |
|---|---|---|
| committer | Nico Weber <thakis@chromium.org> | 2021-10-06 10:50:02 -0400 |
| commit | f9457f1f88b3e835fca8942b5272f3ecf26d4e98 (patch) | |
| tree | b34c0f5aca4e37b473b85fe840649fa3b1f77145 /llvm/lib/Bitcode/Reader/BitcodeReader.cpp | |
| parent | ff41fc07b12bd7bf3c8cd238824b16b1066fe5a0 (diff) | |
[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
Diffstat (limited to 'llvm/lib/Bitcode/Reader/BitcodeReader.cpp')
0 files changed, 0 insertions, 0 deletions
