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
412dbebe1b
license change
...
llvm-svn: 119395
2010-11-16 22:09:02 +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
88efc1c7a5
Contemplating this <atomic> reorganization...
...
llvm-svn: 115087
2010-09-29 21:20:03 +00:00
7d489d7a73
Didn't mean to commit that one
...
llvm-svn: 115058
2010-09-29 18:33:45 +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
Howard Hinnant