summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema/atomic-ops.c
Commit message (Collapse)AuthorAgeFilesLines
* Atomics: support min/max orthogonallyTim Northover2019-11-211-2/+30
| | | | | | | | | | | | We seem to have been gradually growing support for atomic min/max operations (exposing longstanding IR atomicrmw instructions). But until now there have been gaps in the expected intrinsics. This adds support for the C11-style intrinsics (i.e. taking _Atomic, rather than individually blessed by C11 standard), and the variants that return the new value instead of the original one. That way, people won't be misled by trying one form and it not working, and the front-end is more friendly to people using _Atomic types, as we recommend.
* Add -fgnuc-version= to control __GNUC__ and other GCC macrosReid Kleckner2019-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that compiling on Windows with -fno-ms-compatibility had the side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and a number of other macros for GCC compatibility. This is undesirable and causes Chromium to do things like mix __attribute__ and __declspec, which doesn't work. We should have a positive language option to enable GCC compatibility features so that we can experiment with -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be that option. My issue aside, users have, for a long time, reported that __GNUC__ doesn't match their expectations in one way or another. We have encouraged users to migrate code away from this macro, but new code continues to be written assuming a GCC-only environment. There's really nothing we can do to stop that. By adding this flag, we can allow them to choose their own adventure with __GNUC__. This overlaps a bit with the "GNUMode" language option from -std=gnu*. The gnu language mode tends to enable non-conforming behaviors that we'd rather not enable by default, but the we want to set things like __GXX_RTTI__ by default, so I've kept these separate. Helps address PR42817 Reviewed By: hans, nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D68055 llvm-svn: 374449
* __c11_atomic_load's _Atomic can be constJF Bastien2018-08-021-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). clang’s lib/Headers/stdatomic.h implements these as #define to the __c11_* equivalent, which are builtins with custom typecheck. Fix the typecheck. D47613 takes care of the libc++ side. Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html <rdar://problem/27426936> Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47618 llvm-svn: 338743
* Follow-up fix for nonnull atomic non-member functionsJF Bastien2018-05-251-1/+66
| | | | | | | | Handling of the third parameter was only checking for *_n and not for the C11 variant, which means that cmpxchg of a 'desired' 0 value was erroneously warning. Handle C11 properly, and add extgensive tests for this as well as NULL pointers in a bunch of places. Fixes r333246 from D47229. llvm-svn: 333290
* Make atomic non-member functions as nonnullJF Bastien2018-05-251-4/+76
| | | | | | | | | | | | | | | | | Summary: As a companion to libc++ patch https://reviews.llvm.org/D47225, mark builtin atomic non-member functions which accept pointers as nonnull. 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). <rdar://problem/18473124> Reviewers: arphaman Subscribers: aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D47229 llvm-svn: 333246
* Added atomic_fetch_min, max, umin, umax intrinsics to clang.Elena Demikhovsky2018-05-131-0/+17
| | | | | | | | | These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering. Updated the clang-extensions document. Differential Revision: https://reviews.llvm.org/D46386 llvm-svn: 332193
* Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode.Eric Fiselier2017-04-201-0/+10
| | | | | | | | | | | | | | | | | Summary: Libc++ currently implements the `ATOMIC_<TYPE>_LOCK_FREE` macros using the `__GCC_ATOMIC_<TYPE>_LOCK_FREE` macros. However these are not available when MSVC compatibility is enabled even though C11 `_Atomic` is. This prevents libc++ from correctly implementing `ATOMIC_<TYPE>_LOCK_FREE`. This patch adds an alternative spelling `__CLANG_ATOMIC_<TYPE>_LOCK_FREE` that is enabled with `-fms-compatibility`. Reviewers: rsmith, aaron.ballman, majnemer, zturner, compnerd, jfb, rnk Reviewed By: rsmith Subscribers: BillyONeal, smeenai, jfb, cfe-commits, dschuff Differential Revision: https://reviews.llvm.org/D32265 llvm-svn: 300914
* Revert r291477 "[Frontend] Correct values of ATOMIC_*_LOCK_FREE to match ↵Hans Wennborg2017-02-241-0/+4
| | | | | | | | | builtin" It caused PR31864. There is a patch in progress to fix that, but let's revert in the meantime. llvm-svn: 296063
* [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtinMichal Gorny2017-01-091-4/+0
| | | | | | | | | | | | | | | | | | | | | | | Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not to rely on the ABI alignment of types. Instead, just assume all those types are aligned correctly by default since clang uses safe alignment for _Atomic types even if the underlying types are aligned to a lower boundary by default. For example, the 'long long' and 'double' types on x86 are aligned to 32-bit boundary by default. However, '_Atomic long long' and '_Atomic double' are aligned to 64-bit boundary, therefore satisfying the requirements of lock-free atomic operations. This fixes PR #19355 by correcting the value of __GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing the assumption made in libc++ tests. This also fixes PR #30581 by applying a consistent logic between the functions used to implement both interfaces. Differential Revision: https://reviews.llvm.org/D28213 llvm-svn: 291477
* [Sema][Atomics] Treat expected pointer in compare exchange atomics as _NonnullAlex Lorenz2016-11-231-7/+12
| | | | | | | | | | | This commit teaches clang that is has to emit a warning when NULL is passed as the 'expected' pointer parameter into an atomic compare exchange call. rdar://18926650 Differential Revision: https://reviews.llvm.org/D26978 llvm-svn: 287776
* Fix deduction of __atomic_load's parameter types.Eric Fiselier2016-03-301-1/+4
| | | | | | | | | | | | | | Summary: __atomic_load's allows it's first argument to be a pointer to a const type. However the second argument is an output parameter and must be a pointer to non-const. This patch fixes the signature of __atomic_load generated by clang so that it respects the above requirements. Reviewers: rsmith, majnemer Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D13420 llvm-svn: 264967
* [OpenCL] Fix atomic Builtins check for address spaces of non-atomic pointerAnastasia Stulova2015-12-221-0/+6
| | | | | | | | | | | If there are two pointers passed to an atomic Builtin, Clang doesn't allow the second (non-atomic) one to be qualified with an address space. Remove this restriction by recording the address space of passed pointers in atomics type diagnostics. llvm-svn: 256243
* Diagnose const atomics in __atomic builtins.Eric Fiselier2015-10-041-7/+32
| | | | | | | | | | | Diagnose when a pointer to const T is used as the first argument in at atomic builtin unless that builtin is a load operation. This is already checked for C11 atomics builtins but not for __atomic ones. This patch was given the LGTM by rsmith when it was part of a larger review. (See http://reviews.llvm.org/D10407) llvm-svn: 249252
* Sema: Ensure that __c11_atomic_fetch_add has a pointer to complete typeDavid Majnemer2015-01-281-1/+5
| | | | | | | | Pointer arithmetic is only makes sense if the pointee type is complete. This fixes PR22361. llvm-svn: 227295
* Make test/Sema/atomic-ops.c free-standingHal Finkel2014-10-031-1/+1
| | | | | | | | This test includes stdint.h, which might include system headers (and that might not work, depending on the system configuration). Attempting to fix llvm-clang-lld-x86_64-debian-fast. llvm-svn: 218959
* Add an implementation of C11's stdatomic.hHal Finkel2014-10-031-4/+67
| | | | | | | | | | | | | | | | | | | | | | | | Adds a Clang-specific implementation of C11's stdatomic.h header. On systems, such as FreeBSD, where a stdatomic.h header is already provided, we defer to that header instead (using our __has_include_next technology). Otherwise, we provide an implementation in terms of our __c11_atomic_* intrinsics (that were created for this purpose). C11 7.1.4p1 requires function declarations for atomic_thread_fence, atomic_signal_fence, atomic_flag_test_and_set, atomic_flag_test_and_set_explicit, and atomic_flag_clear, and requires that they have external linkage. Accordingly, we provide these declarations, but if a user elides the shadowing macros and uses them, then they must have a libc (or similar) that actually provides definitions. atomic_flag is implemented using _Bool as the underlying type. This is consistent with the implementation provided by FreeBSD and also GCC 4.9 (at least when __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1). Patch by Richard Smith (rebased and slightly edited by me -- Richard said I should drive at this point). llvm-svn: 218957
* AArch64/ARM64: update Clang after AArch64 removal.Tim Northover2014-05-241-1/+0
| | | | | | | | | | | A few (mostly CodeGen) parts of Clang were tightly coupled to the AArch64 backend. Now that it's gone, they will not even compile. I've also deduplicated RUN lines in many of the AArch64 tests. This might improve "make check-all" time noticably: some of those NEON tests were monsters. llvm-svn: 209578
* Sema: demote invalid atomic ordering message to warning.Tim Northover2014-03-111-17/+17
| | | | | | | | | | | | | | Someone could write: if (0) { __c11_atomic_load(ptr, memory_order_release); } or the equivalent, which is perfectly valid, so we shouldn't outright reject invalid orderings on purely static grounds. rdar://problem/16242991 llvm-svn: 203564
* Sema: produce error when invalid ordering is passed to atomic builtinTim Northover2014-03-111-0/+222
| | | | | | | | | This is a conservative check, because it's valid for the expression to be non-constant, and in cases like that we just don't know whether it's valid. rdar://problem/16242991 llvm-svn: 203561
* Handle init lists and _Atomic fields.Eli Friedman2013-08-191-0/+6
| | | | | | Fixes PR16931. llvm-svn: 188718
* ARM: implement low-level intrinsics for the atomic exclusive operations.Tim Northover2013-07-161-5/+5
| | | | | | | | | | | | This adds three overloaded intrinsics to Clang: T __builtin_arm_ldrex(const volatile T *addr) int __builtin_arm_strex(T val, volatile T *addr) void __builtin_arm_clrex() The intent is that these do what users would expect when given most sensible types. Currently, "sensible" translates to ints, floats and pointers. llvm-svn: 186394
* Add test for PR12527 (bug has apparently already been fixed).Richard Smith2013-04-011-0/+3
| | | | llvm-svn: 178476
* AArch64: add atomic support parameters to TargetInfoTim Northover2013-02-181-0/+5
| | | | | | | | This allows Clang to detect and deal wih __atomic_* operations properly on AArch64. Previously we produced an error when encountering them at high optimisation levels. llvm-svn: 175438
* const _Atomic(T) is not an atomic type, so do not allow it as the type 'A' inRichard Smith2012-09-151-1/+6
| | | | | | | C11 7.17's atomic operations. GNU's __atomic_* builtins do allow const-qualified atomics, though (!!) so don't restrict those. llvm-svn: 163964
* Implement the missing pieces needed to support libstdc++4.7's <atomic>:Richard Smith2012-04-131-8/+76
| | | | | | | | | | | | | | | | | | | | | | | | __atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_* predefined macros. Implement library fallback for __atomic_is_lock_free and __c11_atomic_is_lock_free, and implement __atomic_always_lock_free. Contrary to their documentation, GCC's __atomic_fetch_add family don't multiply the operand by sizeof(T) when operating on a pointer type. libstdc++ relies on this quirk. Remove this handling for all but the __c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins. Contrary to their documentation, __atomic_test_and_set and __atomic_clear take a first argument of type 'volatile void *', not 'void *' or 'bool *', and __atomic_is_lock_free and __atomic_always_lock_free have an argument of type 'const volatile void *', not 'void *'. With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite, except for a couple of libstdc++ bugs and some cases where libc++'s test suite tests for properties which implementations have latitude to vary. llvm-svn: 154640
* Implement support for 18 of the GNU-compatible __atomic builtins.Richard Smith2012-04-121-7/+67
| | | | | | | | | | | | This is not quite sufficient for libstdc++'s <atomic>: we still need __atomic_test_and_set and __atomic_clear, and may need a more complete __atomic_is_lock_free implementation. We are also missing an implementation of __atomic_always_lock_free, __atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed for libstdc++. llvm-svn: 154579
* Provide, and document, a set of __c11_atomic_* intrinsics to implement C11'sRichard Smith2012-04-111-26/+26
| | | | | | | | | <stdatomic.h> header. In passing, fix LanguageExtensions to note that C11 and C++11 are no longer "upcoming standards" but are now actually standardized. llvm-svn: 154513
* Initial implementation of __atomic_* (everything except __atomic_is_lock_free).Eli Friedman2011-10-111-0/+37
llvm-svn: 141632
OpenPOWER on IntegriCloud