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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333776 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333351 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333325 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@332413 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@331379 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@300920 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@287321 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276507 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276506 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@268355 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@255585 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@245463 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@239648 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@225280 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@215305 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@180945 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@154521 91177308-0d34-0410-b5e6-96231b3b80d8
initialisation, do the right thing with regard to atomic initialisation.
Note: clang r154507 or later required for <atomic> to work now.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@154508 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@146865 91177308-0d34-0410-b5e6-96231b3b80d8
