summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/Atomics.c
Commit message (Collapse)AuthorAgeFilesLines
* Added atomic_fetch_min, max, umin, umax intrinsics to clang.Elena Demikhovsky2018-05-131-0/+7
| | | | | | | | | 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 __sync_fetch_and_nand (again)Hal Finkel2014-10-021-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to GCC 4.4, __sync_fetch_and_nand was implemented as: { tmp = *ptr; *ptr = ~tmp & value; return tmp; } but this was changed in GCC 4.4 to be: { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } in response to this change, support for sync_fetch_and_nand (and sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code depending on the old semantics. However, at this point: 1. Many years have passed, and the amount of code relying on the old semantics is likely smaller. 2. Through the work of many contributors, all LLVM backends have been updated such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process was complete July of 2014 (added to the release notes in r212635). 3. The lack of this intrinsic is now a needless impediment to porting codes from GCC to Clang (I've now seen several examples of this). It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC 4.2). To compensate for this, and to address the original concern regarding code relying on the old semantics, I've added a warning that specifically details the fact that the semantics have changed and that we provide the newer semantics. Fixes PR8842. llvm-svn: 218905
* IR-change: cmpxchg operations now return { iN, i1 }.Tim Northover2014-06-131-17/+64
| | | | | | | | This is a minimal fix for clang. I'll soon add support for generating weak variants when requested, but that's not really necessary for the LLVM change in isolation. llvm-svn: 210907
* CHECK-LABEL-ify some code gen tests to improve diagnostic experience when ↵Stephen Lin2013-08-151-2/+2
| | | | | | tests fail. llvm-svn: 188447
* hopefully fix a bunch of ARM buildbot failuresNuno Lopes2012-05-091-1/+1
| | | | llvm-svn: 156513
* Re-commit r139643.Eli Friedman2011-09-131-9/+8
| | | | | | Make clang use Acquire loads and Release stores where necessary. llvm-svn: 139650
* Revert r139643 while I look into it; it's breaking selfhost.Eli Friedman2011-09-131-8/+9
| | | | llvm-svn: 139648
* Make clang use Acquire loads and Release stores where necessary.Eli Friedman2011-09-131-9/+8
| | | | llvm-svn: 139643
* Switch clang over to using fence/atomicrmw/cmpxchg instead of the intrinsics ↵Eli Friedman2011-09-071-180/+172
| | | | | | | | | | (which will go away). LLVM CodeGen does almost exactly the same thing with these and the old intrinsics, so I'm reasonably confident this will not break anything. There are still a few issues which need to be resolved with code generation for atomic load and store, so I'm not converting the places which need those for now. I'm not entirely sure what to do about __builtin_llvm_memory_barrier: the fence instruction doesn't expose all the possibilities which can be expressed by __builtin_llvm_memory_barrier. I would appreciate hearing from anyone who is using this intrinsic. llvm-svn: 139216
* This works on arm.Eric Christopher2011-07-281-1/+1
| | | | llvm-svn: 136303
* Migrate most of the rest of test/FrontendC from llvm and migrateEric Christopher2011-07-261-0/+212
most of them to FileCheck. llvm-svn: 136159
OpenPOWER on IntegriCloud