da9ca0b405
Stephan Tolksdorf: fixes the issue in the <atomic> header and adds 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
2013-05-02 20:18:43 +00:00
ead15d1f95
Implement the ATOMIC_*_LOCK_FREE macros.
...
llvm-svn: 173084
2013-01-21 20:39:41 +00:00
114676622f
atomic_bool was missing (just a typedef to atomic<bool>).
...
llvm-svn: 171498
2013-01-04 18:58:50 +00:00
a0bc10dca6
Align <atomic> with clang r163964 which disallows const _Atomic types.
...
llvm-svn: 164004
2012-09-16 20:33:09 +00:00
d01320c200
Apply noexcept and constexpr to <atomic>.
...
llvm-svn: 154526
2012-04-11 20:14:21 +00:00
766e8ccbfc
Switch libc++ from __atomic_* builtins to __c11_atomic_* builtins.
...
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
2012-04-11 18:55:46 +00:00
cd42f9446b
Now that clang supports doing the right thing with regard to atomic
...
initialisation, do the right thing with regard to atomic initialisation.
Note: clang r154507 or later required for <atomic> to work now.
llvm-svn: 154508
2012-04-11 17:26:23 +00:00
c5d5a98815
Fix use of __atomic_is_lock_free() intrinsic.
...
llvm-svn: 154093
2012-04-05 13:13:24 +00:00
18e33935f3
Some fixes to <atomic> operations to explicitly use atomic types and operations.
...
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
2011-12-19 11:44:20 +00:00
073458b1ab
Windows support by Ruben Van Boxem.
...
llvm-svn: 142235
2011-10-17 20:05:10 +00:00
890477f333
Provide a more readable error message for <atomic> until it is implemented.
...
llvm-svn: 128636
2011-03-31 16:39:39 +00:00
b5452b3db5
After a long break to wait for the atomic spec to settle, this completes the library part of <atomic>. It currently won't even parse as it depends on the existence of the intrinsics specified at http://libcxx.llvm.org/atomic_design_a.html . Everything has been tested using fake intrinsics which have now been removed. As the intrinsics come online, the ATOMIC_* macros will need to be adjusted to reflect which operations are lock-free. These macros will probably need to be #ifdef'd for each supported platform.
...
llvm-svn: 121267
2010-12-08 17:20:28 +00:00
c5f5f0a166
atomics ...
...
llvm-svn: 121204
2010-12-07 23:24:41 +00:00
c772a62096
Work on <atomic> continues. The file size is actually sane now...
...
llvm-svn: 121181
2010-12-07 20:46:14 +00:00
9847abacb1
Getting <atomic> warmed back up. We have a hopefully more stable spec now. And I believe the intrinsic spec at http://libcxx.llvm.org/atomic_design_a.html is still good.
...
llvm-svn: 121064
2010-12-06 23:10:08 +00:00
a7c2f3eac3
[atomics.types.address]
...
llvm-svn: 117033
2010-10-21 17:44:19 +00:00
f9c02e15c4
atomic_schar, atomic_uchar, atomic_short, atomic_ushort, atomic_int, atomic_uint, atomic_long, atomic_ulong, atomic_llong, atomic_ullong, atomic_char16_t, atomic_char32_t and atomic_wchar_t.
...
llvm-svn: 116860
2010-10-19 21:22:10 +00:00
d89b01e521
atomic_char
...
llvm-svn: 116813
2010-10-19 16:51:18 +00:00
b2b5513dcc
Changing <atomic> to follow Design A
...
llvm-svn: 116742
2010-10-18 20:39:07 +00:00
772699070e
Make flag type configurable by the compiler
...
llvm-svn: 115614
2010-10-05 14:02:23 +00:00
668523a1b8
Filling out the infrastructure in <atomic>
...
llvm-svn: 115577
2010-10-04 23:55:35 +00:00
2b672e24a5
Still working on the basic design of <atomic>. I'm working towards a system by which the compiler only needs to define the strongest intrinsics it can. Weaker atomics in the library automatically try stronger and stronger variants, picking the weakest compiler intrinsic available. If no compiler intrinsics are available for a given operation, the library locks a mutex and does the job. Better documentation to follow...
...
llvm-svn: 115538
2010-10-04 18:52:54 +00:00
748a5279b1
[atomics.flag] completed. Initialization is not working on clang and can't be made to work without defaulted default constructors.
...
llvm-svn: 115207
2010-09-30 21:05:29 +00:00
a31e741ac9
Name change of intrinsics as suggested by Jeffrey Yasskin
...
llvm-svn: 115145
2010-09-30 14:04:35 +00:00
88efc1c7a5
Contemplating this <atomic> reorganization...
...
llvm-svn: 115087
2010-09-29 21:20:03 +00:00
7387390d6e
Wrestling with the slowly dawning realization that <atomic> isn't implementable on any compiler at my disposal...
...
llvm-svn: 115054
2010-09-29 18:13:54 +00:00
cfe0b0a1ab
[atomics.order]
...
llvm-svn: 114966
2010-09-28 17:13:38 +00:00
cd39d413b4
Getting started on <atomic>
...
llvm-svn: 114887
2010-09-27 21:17:38 +00:00
Howard Hinnant