summaryrefslogtreecommitdiffstats
path: root/libcxx/include/atomic
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Use __extension__ in a portable mannerLouis Dionne2019-09-041-1/+1
| | | | llvm-svn: 370889
* [libc++] Mark usage of _Atomic with __extension__Louis Dionne2019-09-031-1/+1
| | | | | | | | | An upcoming change in Clang will flag _Atomic as being a C11 extension. To avoid generating this warning in libc++, this commit marks the only use of _Atomic with the __extension__ extension, which suppresses such warnings. llvm-svn: 370796
* Add noexcept throughout <atomic>Eric Fiselier2019-06-231-28/+28
| | | | | | | | | | | The CMake CheckLibcxxAtomic module was always failing to compile the example, even when libatomic wasn't needed. This was caused because the check doesn't link a C++ runtime library to provide std::terminate, which is required for exception support. The check is still really broken, but <atomic> is better! llvm-svn: 364146
* Fix C++03 build failureEric Fiselier2019-03-081-1/+1
| | | | llvm-svn: 355758
* Unbork `std::memory_order` ABI.Eric Fiselier2019-03-081-6/+29
| | | | | | | | | | | | | | | | | | | Summary: We need to pin the underlying type of C++20' `std::memory_order` to match the C++17 version. Anything less is an ABI break. At the moment it's `unsigned` before C++20 and `int` after. Or if you're using `-fshort-enums` it's `unsigned char` before C++20 and `int` after. This patch explicitly specifies the underlying type of the C++20 `memory_order` to be w/e type the compiler would have chosen for the C++17 version. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: jfb, jdoerfert, #libc, zoecarver Differential Revision: https://reviews.llvm.org/D59063 llvm-svn: 355755
* [libc++] Do not specify the underlying type of memory_orderLouis Dionne2019-03-061-8/+2
| | | | | | | | | | | | | | | | Summary: This breaks ABI for folks using -fshort-enums, and does not really buy us anything. http://llvm.org/PR40977 Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver Differential Revision: https://reviews.llvm.org/D59029 llvm-svn: 355521
* Reinstate libc++ patches now that the lldb formatter has been updated.Davide Italiano2019-03-051-253/+791
| | | | | | | | "[libc++] Fix <atomic> failures on GCC" "[libc++] Change memory_order to an enum class" "[libc++] decoupling Freestanding atomic<T> from libatomic.a" llvm-svn: 355427
* [libcxx] Revert set of atomic patches that broke lldb.Davide Italiano2019-03-051-791/+253
| | | | | | | | | | | Revert "[libc++] Fix <atomic> failures on GCC" Revert "[libc++] Change memory_order to an enum class" Revert "[libc++] decoupling Freestanding atomic<T> from libatomic.a" The lldb formatter nededs to be updated. Shafik and Louis will coordinate to do so. llvm-svn: 355417
* [libc++] Fix <atomic> failures on GCCLouis Dionne2019-03-051-86/+86
| | | | | | | | | | | | | | | | Summary: In https://reviews.llvm.org/D58201, we turned memory_order into an enum class in C++20 mode. However, we were not casting memory_order to its underlying type correctly for the GCC implementation, which broke the build bots. I also fixed a test that was failing in C++17 mode on GCC 5. Reviewers: EricWF, jfb, mclow.lists Subscribers: zoecarver Differential Revision: https://reviews.llvm.org/D58966 llvm-svn: 355409
* [libc++] Change memory_order to an enum classLouis Dionne2019-03-051-50/+82
| | | | | | | | | This implements P0439R0. Thanks to Zoe Carver for the patch. Differential Revision: https://reviews.llvm.org/D58201 llvm-svn: 355403
* [libc++] decoupling Freestanding atomic<T> from libatomic.aLouis Dionne2019-03-041-238/+744
| | | | | | | | | | | This patch introduces non-lockfree atomics that do not require using an external libatomic. This work is done with the long-term goal of allowing the use of <atomic> in freestanding environments. Thanks to Olivier Giroux for the patch. Differential Revision: https://reviews.llvm.org/D56913 llvm-svn: 355318
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Implement the infrastructure for feature-test macros. Very few actual ↵Marshall Clow2018-09-121-4/+1
| | | | | | feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955 llvm-svn: 342073
* Mark __c11_atomic_load as constJF Bastien2018-06-011-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part). This patch fixes the libc++ version of the __c11_atomic_load builtins defined for GCC's compatibility sake. D47618 takes care of the clang side. Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html <rdar://problem/27426936> Reviewers: EricWF, mclow.lists Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D47613 llvm-svn: 333776
* Revert "Add nonnull; use it for atomics"JF Bastien2018-05-261-129/+23
| | | | | | | | | | | | | | That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT" r333327. Marshall asked to revert: Let's have a discussion about how to implement this so that it is more friendly to people with installed code bases. We've had *extremely* loud responses to unilaterally adding warnings - especially ones that can't be easily disabled - to the libc++ code base in the past. llvm-svn: 333351
* Add nonnull; use it for atomicsJF Bastien2018-05-251-23/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that: - A warning should be generated if the argument is null - It is undefined behavior if the argument is null (because a dereference will segfault) This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625 The attributes are documented: - https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html - https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters. In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null. <rdar://problem/18473124> Reviewers: arphaman, EricWF Subscribers: aheejin, christof, cfe-commits Differential Revision: https://reviews.llvm.org/D47225 llvm-svn: 333325
* Emit an error when include <atomic> after <stdatomic.h>Volodymyr Sapsai2018-05-151-0/+3
| | | | | | | | | | | | | | | | | | | | | C11 defines `kill_dependency` as a macro in <stdatomic.h>. When you include <atomic> after <stdatomic.h>, the macro clashes with `std::kill_dependency` and causes multiple errors. Explicit error should help in diagnosing those errors. No change for working code that includes <atomic> before <stdatomic.h>. rdar://problem/27435938 Reviewers: rsmith, EricWF, mclow.lists, jfb Reviewed By: jfb Subscribers: jfb, jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits Differential Revision: https://reviews.llvm.org/D45470 llvm-svn: 332413
* Revert "Emit an error when mixing <stdatomic.h> and <atomic>"Volodymyr Sapsai2018-05-081-3/+0
| | | | | | | It reverts commit r331379 because turned out `__ALLOW_STDC_ATOMICS_IN_CXX__` doesn't work well in practice. llvm-svn: 331818
* Emit an error when mixing <stdatomic.h> and <atomic>Volodymyr Sapsai2018-05-021-0/+3
| | | | | | | | | | | | | | | | | | | | | Atomics in C and C++ are incompatible at the moment and mixing the headers can result in confusing error messages. Emit an error explicitly telling about the incompatibility. Introduce the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++ between C atomics and C++ atomics. rdar://problem/27435938 Reviewers: rsmith, EricWF, mclow.lists Reviewed By: mclow.lists Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits Differential Revision: https://reviews.llvm.org/D45470 llvm-svn: 331379
* Fix static initialization of std::atomic_flag; Fixes PR#37226. Thanks to ↵Marshall Clow2018-04-251-1/+1
| | | | | | Ricky Zhou for the report and test case. llvm-svn: 330828
* Fix ATOMIC_<TYPE>_LOCK_FREE macros on Windows.Eric Fiselier2017-04-201-10/+23
| | | | | | | | | | | | Previously the ATOMIC_<TYPE>_LOCK_FREE macros were implemented using __GCC_ATOMIC_<TYPE>_LOCK_FREE but GCC specific macros are defined when -fms-compatibility is specified. To avoid this Libc++ now tries to use the newly added __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros instead, and only falls back to the GCC versions when the Clang ones aren't available. llvm-svn: 300920
* Diagnose invalid memory orderings in <atomic>Eric Fiselier2017-01-131-0/+32
| | | | llvm-svn: 291976
* Replace _LIBCPP_HAS_NO_DELETED_FUNCTIONS with _LIBCPP_CXX03_LANGEric Fiselier2017-01-061-6/+6
| | | | llvm-svn: 291278
* Remove _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONSEric Fiselier2016-11-181-6/+6
| | | | | | | | libc++ no longer supports C++11 compilers that don't implement `= default`. This patch removes all instances of the feature test macro _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS as well as the potentially dead code it hides. llvm-svn: 287321
* Revert r276506 - Diagnose invalid memory order arguments in <atomic>.Eric Fiselier2016-07-231-78/+0
| | | | | | | | There is a bug in Clang 3.6 and earlier that causes compile failures. I suspect it's due to the usage of member function parameter names in the attributes. llvm-svn: 276507
* [libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179.Eric Fiselier2016-07-231-0/+78
| | | | | | | | | | | | | | | Summary: This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible. In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message. Reviewers: mclow.lists, rsmith, jfb, EricWF Subscribers: bcraig, jfb, rsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D22557 llvm-svn: 276506
* Remove FIXME for feature test macroJF Bastien2016-07-211-1/+0
| | | | | | The value I'd picked was correct, as per the recently published SG10 paper http://wg21.link/p0096r3 llvm-svn: 276309
* Implement LWG#2441: 'Exact-width atomic typedefs should be provided'Marshall Clow2016-06-301-0/+18
| | | | llvm-svn: 274236
* [libcxx] [test] Replace non-Standard "atomic_flag f(false);" with Standard ↵Eric Fiselier2016-05-031-1/+1
| | | | | | | | | | | | | | | | | | "atomic_flag f;" Summary: Replace non-Standard "atomic_flag f(false);" with Standard "atomic_flag f;" in clear tests. Although the value of 'f' is unspecified it shouldn't matter because these tests always call `f.test_and_set()` without checking the result, so the initial state shouldn't matter. The test init03.pass.cpp is explicitly testing this non-Standard extension; It has been moved into the `test/libcxx` directory. Reviewers: mclow.lists, STL_MSFT Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D19758 llvm-svn: 268355
* Implement is_always_lock_freeJF Bastien2016-03-251-11/+32
| | | | | | | | | | | | | | | | | | Summary: This was voted into C++17 at the Jacksonville meeting. The final P0152R1 paper will be in the upcoming post-Jacksonville mailing, and is also available here: http://jfbastien.github.io/papers/P0152R1.html Reviewers: mclow.lists, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D17951 llvm-svn: 264413
* Fix various GCC mis-configurations for newer versions.Eric Fiselier2015-12-151-0/+6
| | | | | | | | | | | | This patch goes through and enables C++11 and C++14 features for newer GCC's. The main changes are: 1. Turn on variable templates. (Uses __cpp_variable_templates) 2. Assert atomic<Tp> is trivially copyable (Uses _GNUC_VER >= 501). 3. Turn on trailing return support for GCC. (Uses _GNUC_VER >= 404) 4. XFAIL void_t test for GCC 5.1 and 5.2. Fixed in GCC 6. llvm-svn: 255585
* Fix GCC atomic implementation in C++03Eric Fiselier2015-10-141-3/+8
| | | | llvm-svn: 250279
* [libcxx] Allow use of <atomic> in C++03. Try 3.Eric Fiselier2015-08-191-14/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initialization is a concern the syntax required to get it is C++11 only. Meaning that C++11 constant static initialization cannot silently break in C++03, it will always cause a syntax error. Furthermore `ATOMIC_VAR_INIT` and `ATOMIC_FLAG_INIT` remain defined in C++03 even though they cannot be used because C++03 usages will cause better error messages. The main change in this patch is to replace `__has_feature(cxx_atomic)`, which only returns true when C++ >= 11, to `__has_extension(c_atomic)` which returns true whenever clang supports the required atomic builtins. This patch adds the following macros: * `_LIBCPP_HAS_C_ATOMIC_IMP` - Defined on clang versions which provide the C `_Atomic` keyword. * `_LIBCPP_HAS_GCC_ATOMIC_IMP` - Defined on GCC > 4.7. We must use the fallback atomic implementation. * `_LIBCPP_HAS_NO_ATOMIC_HEADER` - Defined when it is not safe to include `<atomic>`. `_LIBCPP_HAS_C_ATOMIC_IMP` and `_LIBCPP_HAS_GCC_ATOMIC_IMP` are mutually exclusive, only one should be defined. If neither is defined then `<atomic>` is not implemented and including `<atomic>` will issue an error. Reviewers: chandlerc, jroelofs, mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11555 llvm-svn: 245463
* Fix PR24114 - std::atomic for non-Clang is not a literal typeEric Fiselier2015-07-141-1/+2
| | | | | | Add _LIBCPP_CONSTEXPR to the implementation of __gcc_atomic_t. llvm-svn: 242172
* Prevent dependancy on libatomic when using GCC to provide <atomic>.Eric Fiselier2015-06-131-6/+8
| | | | | | | | | The __atomic_is_lock_free(...) function sometimes requires linkage to libatomic if it cannot be evaluated at compile time. Remove __c11_atomic_is_lock_free and use __atomic_is_lock_free(sizeof(Tp)) directly so that it can be evaluated at compile time. llvm-svn: 239648
* Change a couple more template parameter names from 'T' to '_Tp', etc. Thanks ↵Marshall Clow2015-01-111-9/+9
| | | | | | to Ondřej Majerech for the patch, but I did a bit more. llvm-svn: 225598
* Obey [atomics.types.operations.req]/21 for GCC.Dan Albert2015-01-061-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Excerpt from [atomics.types.operations.req]/21: > When only one memory_order argument is supplied, the value of > success is order, and the value of failure is order except that a > value of memory_order_acq_rel shall be replaced by the value > memory_order_acquire and a value of memory_order_release shall be > replaced by the value memory_order_relaxed. Clean up some copy pasta while I'm here (someone added a return statement to a void function). Reviewers: EricWF, jroelofs, mclow.lists Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6632 llvm-svn: 225280
* Allow libc++ to be built on systems without POSIX threadsJonathan Roelofs2014-09-051-0/+6
| | | | | | | | | | If you're crazy enough to want this sort of thing, then add -D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and --param=additiona_features=libcpp-has-no-threads to your lit commnad line. http://reviews.llvm.org/D3969 llvm-svn: 217271
* Emulate clang atomic built-ins on gcc > 4.7Dan Albert2014-08-091-1/+252
| | | | | | | | | | | | gcc 4.7 and above has atomic built-ins which slightly different APIs from those provided by clang. Add proxy functions that wrap the gcc built-ins to produce a symbol that is API equivalent to the clang built-ins. This allows libc++'s atomic library to be used with gcc-4.7 and newer. Patch contributed by Albert Wong. llvm-svn: 215305
* Stephan Tolksdorf: fixes the issue in the <atomic> header and adds ↵Howard Hinnant2013-05-021-5/+15
| | | | | | | | corresponding tests. I've used macros to fall back to a user-provided default constructor if _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS (though I suspect that there won't be many users defining that macro). The tests use placement new to check that atomic values get properly zero-initialized. I had to modify the atomic_is_lock_free test, because default initialization of an object of const type 'const A' (aka 'const atomic<int>') requires a user-provided default constructor. llvm-svn: 180945
* Implement the ATOMIC_*_LOCK_FREE macros.Howard Hinnant2013-01-211-8/+12
| | | | llvm-svn: 173084
* atomic_bool was missing (just a typedef to atomic<bool>).Howard Hinnant2013-01-041-0/+2
| | | | llvm-svn: 171498
* Align <atomic> with clang r163964 which disallows const _Atomic types.Howard Hinnant2012-09-161-1/+1
| | | | llvm-svn: 164004
* Apply noexcept and constexpr to <atomic>.Howard Hinnant2012-04-111-323/+323
| | | | llvm-svn: 154526
* Switch libc++ from __atomic_* builtins to __c11_atomic_* builtins.Richard Smith2012-04-111-38/+38
| | | | | | | | | | Per discussion with Howard, we are not interested in maintaining compatibility with older versions of clang. All tests pass with ToT clang, except for two which assert due to a pre-existing, unrelated bug. llvm-svn: 154521
* Now that clang supports doing the right thing with regard to atomicDavid Chisnall2012-04-111-4/+4
| | | | | | | initialisation, do the right thing with regard to atomic initialisation. Note: clang r154507 or later required for <atomic> to work now. llvm-svn: 154508
* Fix use of __atomic_is_lock_free() intrinsic.David Chisnall2012-04-051-2/+2
| | | | llvm-svn: 154093
* Some fixes to <atomic> operations to explicitly use atomic types and operations.David Chisnall2011-12-191-6/+6
| | | | | | | The integral types now work with clang trunk (if you remove the guard), although we're still missing an intrinsic for initialising atomics (needed for C1x too). Howard: Please review. llvm-svn: 146865
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* Provide a more readable error message for <atomic> until it is implemented.Howard Hinnant2011-03-311-0/+6
| | | | llvm-svn: 128636
OpenPOWER on IntegriCloud