summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
diff options
context:
space:
mode:
authorNico Weber <thakis@chromium.org>2021-10-06 10:30:14 -0400
committerNico Weber <thakis@chromium.org>2021-10-06 10:50:02 -0400
commitf9457f1f88b3e835fca8942b5272f3ecf26d4e98 (patch)
treeb34c0f5aca4e37b473b85fe840649fa3b1f77145 /llvm/lib/Bitcode/Reader/BitcodeReader.cpp
parentff41fc07b12bd7bf3c8cd238824b16b1066fe5a0 (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