call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load has to be an acquire atomic load.

Differential Revision: https://reviews.llvm.org/D24028

llvm-svn: 280621

llvm-svn: 272804

Summary:
This patch implements the variadic `lock_guard` paper. 

Making `lock_guard` variadic is a ABI breaking change because the specialization `lock_guard<_Mutex>` mangles differently then when it was the primary template. This change only provides variadic `lock_guard` in ABI V2 or when `_LIBCPP_ABI_VARIADIC_LOCK_GUARD` is defined.

Note that in ABI V2 `lock_guard` must always be declared as a variadic template, even in C++03, in order to keep the ABI consistent. For this reason `lock_guard` is forward declared as a variadic template in all standard dialects and therefore depends on variadic templates being provided as an extension in C++03. All supported versions of Clang and GCC provide this extension.




Reviewers: mclow.lists

Subscribers: K-ballo, mclow.lists, cfe-commits

Differential Revision: http://reviews.llvm.org/D21260

llvm-svn: 272634

This patch extracts out all the pthread dependencies of libcxx into the
new header __threading_support. The motivation is to make it easy to
re-target libcxx into platforms that do not support pthread.

Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781

Applied with tweaks - D19412

Change-Id: I301111f0075de93dd8129416e06babc195aa936b
llvm-svn: 268734

Patch by Philippe Daouadi!

http://reviews.llvm.org/D9639

llvm-svn: 246168

Summary:
In some places in libc++ we need to use the `__atomic_*` builtins. This patch adds a header that provides access to those builtins in a uniform way from within the dylib source.

If the compiler building the dylib does not support these builtins then a warning is issued.

Only relaxed loads are needed within the headers. A singe function to do these relaxed loads has been added to `<memory>`.

This patch applies the new atomic builtins to `__shared_count` and `call_once`.

Reviewers: mclow.lists

Subscribers: majnemer, jroelofs, cfe-commits

Differential Revision: http://reviews.llvm.org/D10406

llvm-svn: 241532

This patch fixes LWG issue 2422 by removing the DECAY_COPY from call once.
The review can be found here: http://reviews.llvm.org/D10191

llvm-svn: 239654

It might be implicitly included by <pthread.h> (and that's why it worked
so far), but it's not guaranteed (for example, this is not the case with
newlib).

llvm-svn: 223661

If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.

http://reviews.llvm.org/D3969

llvm-svn: 217271

std::once_flag was forward declared with _LIBCPP_TYPE_VIS decoration, and the defined with _LIBCPP_TYPE_VIS_ONLY decoration. Make them match

llvm-svn: 214219

Nico Rieck:  this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.

llvm-svn: 188192

No functionality change at this time.  I've split _LIBCPP_VISIBLE up into two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS.  This is in preparation for taking advantage of clang's new __type_visibility__ attribute.

llvm-svn: 176593

Dimitry Andric:  many visibility fixes.  Howard:  Much appreciated.  Can you send me a patch to CREDITS.TXT?

llvm-svn: 163862

llvm-svn: 160604

llvm-svn: 145624

llvm-svn: 145410

llvm-svn: 145407

llvm-svn: 142235

llvm-svn: 134190

I had a giant misunderstanding of what 'synchronizes with' meant in [futures.async]/p5.  This invalidated the current design of async in <future>.  This is a new design, based on my new understanding, which has been confirmed on the lwg mailing list.  The summary is that ~future() (and ~shared_future()) will block when they are created from within async, and the thread hasn't finished yet.  As part of this work I created two new type traits:  __invokable<F, Args...>::value and __invoke_of<F, Args...>::type.  These are what result_of<F(Args...)> wanted to be when it grew up, but never will be. __invoke_of is carefully crafted so that it can serve as its own enable_if (type doesn't exist if the signature isn't invokable).  All of this work is C++11 only.

llvm-svn: 131639

Brought call_once variadic call up to current spec, which allows move-only functors and move-only arguments, but disallows functors with non-const lvalue reference parameters.

llvm-svn: 131414

llvm-svn: 123337

llvm-svn: 119909

llvm-svn: 119395

llvm-svn: 114559

Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature.

llvm-svn: 113086

llvm-svn: 111750

llvm-svn: 103516

llvm-svn: 103490