| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
aren't supported at the moment. PR12040.
llvm-svn: 152891
|
|
|
|
|
|
| |
Make clang use Acquire loads and Release stores where necessary.
llvm-svn: 139650
|
|
|
|
| |
llvm-svn: 139648
|
|
|
|
| |
llvm-svn: 139643
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
| |
llvm-svn: 137535
|
|
|
|
|
|
| |
Patch by Dave Zarzycki!
llvm-svn: 129189
|
|
|
|
|
|
|
| |
aggressive about the form we expect bools to be in. I don't really have
time to fix all the sources right now.
llvm-svn: 117486
|
|
|
|
| |
llvm-svn: 117456
|
|
|
|
|
|
|
| |
in IR gen, and use those to fix a correctness issue with bool atomic
intrinsics. rdar://problem/8461234
llvm-svn: 117403
|
|
|
|
|
|
| |
atomics
llvm-svn: 114503
|
|
|
|
| |
llvm-svn: 114502
|
|
|
|
| |
llvm-svn: 114498
|
|
|
|
| |
llvm-svn: 114497
|
|
|
|
|
|
| |
fixed return types.
llvm-svn: 108657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
their call expressions synthetically have the "deduced" types based on their
first argument. We only insert conversions in the AST for arguments whose
values require conversion to match the value type expected. This keeps PR7600
closed by maintaining the return type, but avoids assertions due to unexpected
implicit casts making the type unsigned (test case added from Daniel).
The magic is moved into the codegen for the atomic builtin which inserts the
casts as needed at the IR level to raise the type to an integer suitable for
the LLVM intrinsic. This shouldn't cause any real change in functionality, but
now we can make the builtin be more truly polymorphic.
llvm-svn: 108638
|
|
|
|
|
|
|
| |
gcc, and the common expectation seems to be that they are unused. If and when
someone cares we can add them back with well documented demantics.
llvm-svn: 99522
|
|
|
|
|
|
|
|
| |
semantics.
- This should be conservatively correct, we eventually should have target hooks for platforms that are less strict.
llvm-svn: 99050
|
|
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
|
|
|
|
|
| |
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
llvm-svn: 86430
|
|
|
|
|
|
| |
RValue.
llvm-svn: 72504
|
|
|
|
|
|
| |
rdar://6880573
llvm-svn: 71637
|
|
|
|
| |
llvm-svn: 71361
|
|
|
|
|
|
|
|
|
| |
of the underlying _N builtin, not the the type of the pointee of the
actual type. This ensures that atomics involving pointers end up
using the correct integer type when they are resolved, avoiding
aborts in codegen.
llvm-svn: 71218
|
|
|
|
|
|
|
|
|
| |
semantic rules that gcc and icc use. This implements the variadic
and concrete versions as builtins and has sema do the
disambiguation. There are probably a bunch of details to finish up
but this seems like a large monotonic step forward :)
llvm-svn: 71212
|
|
|
|
|
|
|
|
| |
__sync_bool_compare_and_swap.
- <rdar://problem/6762223> [sema/irgen] support
__sync_bool_compare_and_swap and __sync_add_and_fetch
llvm-svn: 68482
|
|
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
|
|
|
| |
llvm-svn: 52754
|
|
|
|
|
|
| |
Otherwise, failing tests other than the last one will not be reported.
llvm-svn: 52231
|
|
llvm-svn: 50919
|