This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] Allow <atomic> to be used in c++03.
AbandonedPublic

Authored by EricWF on Nov 14 2014, 6:24 PM.

Details

Reviewers
None
Summary

There are many places where libc++ want to use <atomic> internally in C++03 code. Unfortunately <atomic> currently only supports C++11 and later. This patch extends <atomic> so that everything except ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT can be used in c++03 code.

This patch introduces the macros:

  • _LIBCPP_HAS_C11_ATOMICS: Defined if __has_extension(c_atomic) is true.
  • _LIBCPP_HAS_CXX_ATOMICS: Defined if we have C11 atomics from clang or the __atomic_* builtin family from GCC and libc++ is configured for threads. If _LIBCPP_HAS_CXX_ATOMICS is defined then the <atomic> header should be safe to include.

Other Misc changes:

  • __gcc_atomic_t default constructs the stored value. This make it perform the same as _Atomic.
  • constexpr -> _LIBCPP_CONSTEXPR
  • noexcept -> TEST_NOEXCEPT in the tests.
  • re-implement std::atomic::is_lock_free() to prevent needing libatomic with GCC.

Everything in atomic works in C++03 except for ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT. These macros are required to allow:

std::atomic_flag f = ATOMIC_FLAG_INIT;

// ATOMIC_VAR_INIT is defined as
#define ATOMIC_VAR_INIT {false}

In c++11 f is aggregate-initialized but in C++03 f is copy-initialized. Since atomic types are not copy-able this results in a compile error in C++03. For this reason the macros are not defined in C++03 mode.

Furthermore initialization of static storage duration atomics using the macros takes place during constant-initialization.(http://en.cppreference.com/w/cpp/language/constant_initialization). This makes statically initialized atomic's safe and easy to use in other static initialization expressions.

There doesn't seem to be a way to implement these macros in C++03. For that reason they are simply removed when __cplusplus < 201103L.

Diff Detail

Event Timeline

EricWF updated this revision to Diff 16258.Nov 14 2014, 6:24 PM
EricWF retitled this revision from to [libcxx] Allow <atomic> to be used in c++03..
EricWF updated this object.
EricWF edited the test plan for this revision. (Show Details)
EricWF added reviewers: mclow.lists, danalbert.
EricWF added a subscriber: Unknown Object (MLST).
EricWF updated this revision to Diff 16260.Nov 14 2014, 6:28 PM

Added missing tests.

danalbert edited edge metadata.Nov 14 2014, 9:33 PM

Not sure what our policy is on allowing C++11 features in pre-C++11 code. I think I'd prefer that people just be required to upgrade to C++11 rather than allowing them to keep living in the past.

I also don't like that we're not implementing a complete <atomic> in C++03 mode. Sounds like another good reason to not support it to me.

I'll defer to mclow on this one. Just my two cents.

In D6284#6, @danalbert wrote:

Not sure what our policy is on allowing C++11 features in pre-C++11 code. I think I'd prefer that people just be required to upgrade to C++11 rather than allowing them to keep living in the past.

libc++ is a C++11 standard library with C++03 compatibility (or at least that is what I've been told). <atomic> is currently the only header that explicitly causes a compile error when included in C++03. Almost every other header seems to give a best effort approach to providing c++03 compatibility. <atomic> works almost perfectly in C++03 already so I don't see why we forbid it.

I also don't like that we're not implementing a complete <atomic> in C++03 mode. Sounds like another good reason to not support it to me.

Fair point. The only lost functionality is initialization with an = sign in it. This is more a loss of syntax than it is functionality.

I'll defer to mclow on this one. Just my two cents.

Thanks for the input. I would just like to know what to do with the tests in C++03 mode :)

@mclow.lists: Ping. We should make a decision on this.

EricWF abandoned this revision.Feb 11 2015, 8:14 PM
EricWF added a subscriber: chandlerc.

@chandlerc made me aware of the static initialization issues. I don't think it is possible to make static initialization happen during constant initialization in c++03. This makes backporting atomic non-viable.

For this reason I am abandoning the revision.

EricWF updated this object.Jun 1 2015, 4:11 PM
EricWF removed reviewers: danalbert, mclow.lists.
EricWF updated this object.
EricWF removed subscribers: chandlerc, Unknown Object (MLST).