This is an archive of the discontinued LLVM Phabricator instance.

[clang] Don't mark _ReadBarrier(), _ReadWriteBarrier(), _WriteBarrier() deprecated
ClosedPublic

Authored by thakis on Oct 6 2021, 7:37 AM.

Details

Summary

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.

Diff Detail

Event Timeline

thakis requested review of this revision.Oct 6 2021, 7:37 AM
thakis created this revision.
hans accepted this revision.Oct 6 2021, 7:47 AM

Sounds very reasonable to me. lgtm

This revision is now accepted and ready to land.Oct 6 2021, 7:47 AM
This revision was landed with ongoing or failed builds.Oct 6 2021, 7:50 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptOct 6 2021, 7:50 AM