Add ABI option to remove recently inlined __shared_count functions from the library.

In order to allow inlining of previously out-of-line functions without an ABI break
libc++ provides legacy defini

Add ABI option to remove recently inlined __shared_count functions from the library.

In order to allow inlining of previously out-of-line functions without an ABI break
libc++ provides legacy definitions in the dylib that old programs can
continue to use. Unfortunatly Windows link.exe detects this hack and diagnoses the duplicate
definitions.

This patch disable the duplicate definitions on Windows by adding an ABI option
which disables all "legacy out-of-line symbols"

llvm-svn: 292190

show more ...

[Test patch] Inline hot functions in libcxx shared_ptr

Moves hot functions such as atomic add into the memory header file
so that they can be inlined, which brings performance benefits.

Patch by Ke

[Test patch] Inline hot functions in libcxx shared_ptr

Moves hot functions such as atomic add into the memory header file
so that they can be inlined, which brings performance benefits.

Patch by Kevin Hu, Aditya Kumar, Sebastian Pop

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

llvm-svn: 292184

show more ...

Fix std::pointer_safety type in ABI v2

In the C++ standard `std::pointer_safety` is defined
as a C++11 strongly typed enum. However libc++ currently defines
it as a class type which simulates a C++1

Fix std::pointer_safety type in ABI v2

In the C++ standard `std::pointer_safety` is defined
as a C++11 strongly typed enum. However libc++ currently defines
it as a class type which simulates a C++11 enumeration. This
can be detected in valid C++ code.

This patch introduces an the _LIBCPP_ABI_POINTER_SAFETY_ENUM_TYPE ABI option.
When defined `std::pointer_safety` is implemented as an enum type.
Unfortunatly this also means it can no longer be provided as an extension
in C++03.

Additionally this patch moves the definition for `get_pointer_safety()`
out of the dylib, and into the headers. New usages of `get_pointer_safety()`
will now use the inline version instead of the dylib version. However in
order to keep the dylib ABI compatible the old definition is explicitly
compiled into it.

llvm-svn: 291046

show more ...

Mark libc++ internal globals with _LIBCPP_SAFE_STATIC.

This patch applies the _LIBCPP_SAFE_STATIC attribute to internal globals,
most of which are locking primitives, in order to ensure that they ca

Mark libc++ internal globals with _LIBCPP_SAFE_STATIC.

This patch applies the _LIBCPP_SAFE_STATIC attribute to internal globals,
most of which are locking primitives, in order to ensure that they can
safely be used during program startup.

This patch also fixes an unsafe static init issue with the global locks
used to implement atomic operations on shared pointers. Previously the
locks were initialized using a dynamically initialized pointer, so it was
possible that the pointer was uninitialized.

llvm-svn: 282640

show more ...

Fixing 'Aquire' typo and libcxx build.

llvm-svn: 277456

Improve shared_ptr dtor performance

If the last destruction is uncontended, skip the atomic store on
__shared_weak_owners_. This shifts some costs from normal
shared_ptr usage to weak_ptr uses.

htt

Improve shared_ptr dtor performance

If the last destruction is uncontended, skip the atomic store on
__shared_weak_owners_. This shifts some costs from normal
shared_ptr usage to weak_ptr uses.

https://reviews.llvm.org/D22470

llvm-svn: 277357

show more ...

Enable building and using atomic shared_ptr for GCC.

Summary:
Currently the implementation of [util.smartptr.shared.atomic] is provided only when using Clang, and not with GCC. This is a relic of n

Enable building and using atomic shared_ptr for GCC.

Summary:
Currently the implementation of [util.smartptr.shared.atomic] is provided only when using Clang, and not with GCC. This is a relic of not having a GCC implementation of <atomic>, even though <atomic> isn't actually used in the implementation. This patch enables support for atomic shared_ptr functions when using GCC.

Note that this is not a header only change. Previously only Clang builds of libc++.so would provide the required symbols. There is no reason for this restriction.
After this change both Clang and GCC builds should be binary compatible with each other WRT these symbols.


Reviewers: mclow.lists, rmaprath, EricWF

Subscribers: cfe-commits

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

llvm-svn: 273076

show more ...

Refactor pthread usage of libcxx.

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 p

Refactor pthread usage of libcxx.

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

show more ...

[libcxx] Allow use of <atomic> in C++03. Try 3.

Summary:
After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initi

[libcxx] Allow use of <atomic> in C++03. Try 3.

Summary:
After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initialization is a concern the syntax required to get it is C++11 only. Meaning that C++11 constant static initialization cannot silently break in C++03, it will always cause a syntax error. Furthermore `ATOMIC_VAR_INIT` and `ATOMIC_FLAG_INIT` remain defined in C++03 even though they cannot be used because C++03 usages will cause better error messages.

The main change in this patch is to replace `__has_feature(cxx_atomic)`, which only returns true when C++ >= 11, to `__has_extension(c_atomic)` which returns true whenever clang supports the required atomic builtins.


This patch adds the following macros:
* `_LIBCPP_HAS_C_ATOMIC_IMP` - Defined on clang versions which provide the C `_Atomic` keyword.
* `_LIBCPP_HAS_GCC_ATOMIC_IMP` - Defined on GCC > 4.7. We must use the fallback atomic implementation.
* `_LIBCPP_HAS_NO_ATOMIC_HEADER` - Defined when it is not safe to include `<atomic>`.

`_LIBCPP_HAS_C_ATOMIC_IMP` and `_LIBCPP_HAS_GCC_ATOMIC_IMP` are mutually exclusive, only one should be defined. If neither is defined then `<atomic>` is not implemented and including `<atomic>` will issue an error.

Reviewers: chandlerc, jroelofs, mclow.lists

Subscribers: cfe-commits

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

llvm-svn: 245463

show more ...

Move atomic_support.h and config_elast.h into src/include

llvm-svn: 245354

[libcxx] Add atomic_support.h header to src that handles needed atomic operations.

Summary:
In some places in libc++ we need to use the `__atomic_*` builtins. This patch adds a header that provides

[libcxx] Add atomic_support.h header to src that handles needed atomic operations.

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

show more ...

Fix building and running tests when LIBCXX_ENABLE_EXCEPTIONS or LIBCXX_ENABLE_RTTI are turned off.

llvm-svn: 224095

Address some post-commit review comments on r217261

llvm-svn: 217276

Allow libc++ to be built on systems without POSIX threads

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-

Allow libc++ to be built on systems without POSIX threads

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

show more ...

Switch to using C++ style casts.

llvm-svn: 198505

This should be nothing but a load-time optimization. I'm trying to reduce load time initializers and this is a big one. No visible functionality change intended.

llvm-svn: 177212

Rename uses of _ and __ because these are getting stepped on by macros from other system code.

llvm-svn: 167038

Patch contributed by Dev Dude for mingw64 port.

llvm-svn: 162188

Despite my pathological distrust of spin locks, the number just don't lie. I've put a small spin in __sp_mut::lock() on std::mutex::try_lock(), which is testing quite well. In my experience, puttin

Despite my pathological distrust of spin locks, the number just don't lie. I've put a small spin in __sp_mut::lock() on std::mutex::try_lock(), which is testing quite well. In my experience, putting in a yield for every failed iteration is also a major performance booster. This change makes one of the performance tests I was using (a highly contended one) run about 20 times faster.

llvm-svn: 160967

show more ...

Implement [util.smartptr.shared.atomic]. This is the last unimplemented
section in libc++. This requires a recompiled dylib. Failure to rebuild
the dylib will result in a link-time error if and on

Implement [util.smartptr.shared.atomic]. This is the last unimplemented
section in libc++. This requires a recompiled dylib. Failure to rebuild
the dylib will result in a link-time error if and only if the functions from
[util.smartptr.shared.atomic] are used.

The implementation is not lock free. After considerable thought, I know of no
way to make the implementation lock free. Ideas welcome along that front. But
changing the ABI of shared_ptr is not on the table at this point.

The mutex used to lock these function is encapsulated by std::__sp_mut. The
only thing the client knows about std::__sp_mut is that it has a void* data
member, can't be constructed, and has lock and unlock members. Within the
binary __sp_mut is currently implemented as a pointer to a std::mutex. That can
change in the future without disturbing the ABI (as long as sizeof(__sp_mut)
remains constant.

I specifically did not make __sp_mut a spin lock as I have a pathological
distrust of spin locks. Testing on OS X reveals that the use of std::mutex in
this role is not a large performance penalty as long as the contention for the
mutex is low (more likely to get the lock than to have to wait). In the future
we can still make __sp_mut a spin lock if that is what is desired (without ABI
damage).

The dylib contains 16 __sp_mut's to be chosen based on the hash of the address
of the shared_ptr. The constant 16 is a ball-park reasonable space/time
tradeoff.

std::hash<T*> was changed to call __murmur2_or_cityhash, instead of the identity
function. I had thought we had already done this, but I was mistaken.

All of this is under #if __has_feature(cxx_atomic) even though the
implementation is not lock free, because the signatures require access to
std::memory_order, which is currently available only under
__has_feature(cxx_atomic).

llvm-svn: 160940

show more ...

Appy constexpr to <memory>. Picked up a few missing noexcepts as well.

llvm-svn: 159902

Fix memory leak in converting weak_ptr to shared_ptr

llvm-svn: 147298

Quash a whole bunch of warnings

llvm-svn: 145624

noexcept for <memory>. I've added a few extension noexcept to: allocator_traits<A>::deallocate, allocaate<T>::deallocate, return_temporary_buffer, and default_delete<T>::operator()(T*) const. My r

noexcept for <memory>. I've added a few extension noexcept to: allocator_traits<A>::deallocate, allocaate<T>::deallocate, return_temporary_buffer, and default_delete<T>::operator()(T*) const. My rationale was: If a std-dicated noexcept function needs to call another std-defined function, that called function must be noexcept. We're all a little new to noexcept, so things like this are to be expected. Also included fix for broken __is_swappable trait pointed out by Marc Glisse, thanks Marc|. And fixed a test case for is_nothrow_destructible. Destructors are now noexcept by default|

llvm-svn: 132261

show more ...

license change

llvm-svn: 119395