This option is geared towards shared library builds and causes static
library builds to fail if not explicitly disabled.
This patch fixes PR27706: https://llvm.org/bugs/show_bug.cgi?id=27706
Thanks rgoodfel@isi.edu for the catch.
llvm-svn: 269585
Summary:
Currently libc++experimental builds with C++11. This patch changes that to C++14 when supported by the compiler. Although nothing currently requires C++14 the upcoming <experimental/memory_resource> implementation would benefit from it. [1]
Note that libc++.so continues to build with C++11 and is unaffected by this change.
[1] <experimental/memory_resource> provides global resources which must exist for the entire lifetime of the program. In order to ensure that a global resource can be used during program termination there destructors must never be invoked. The only way to do this, while also allowing "constant initialization", is to use a C++14 union.
Reviewers: mclow.lists
Subscribers: pete, cfe-commits
Differential Revision: http://reviews.llvm.org/D19992
llvm-svn: 269070
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
Summary:
Out-of-line symbols for <experimental/...> headers are not ABI or API stable and cannot live in the 'libc++.dylib'. Currently they have nowhere to live. I would like to add a new library target `libc++experimental.a` to fix this.
Previously I had suggested different libraries for different TS's (`libc++filesystem.a`, 'libc++LFTS.a`, ect). I no longer think this is the right approach.
Instead `c++experimental` will hold *all* TS implementations as a single monolithic library. I see two main benefits to this:
1. Users only have to know about and manually link one library.
2. It makes it easy to implement TS's with one or two out-of-line symbols. (Ex. PMRs)
`c++experimental` provides NO ABI compatibility. Symbols can freely be added/removed/changed without concern for ABI stability.
I will add documentation for this after landing this patch (but before adding anything to it).
`c++experimental` only builds as a static library. By default CMake will build/test this library but will *NOT* install it.
This patch adds the CMake and LIT logic needed to build/test the new library. Once this lands I plan on using it to implement parts of `<experimental/memory_resource>`.
Reviewers: mclow.lists
Subscribers: cfe-commits, theraven, krememek, dexonsmith, bcraig, beanz, danalbert
Differential Revision: http://reviews.llvm.org/D19856
llvm-svn: 268443
This patch fixes a bunch of bugs in the fallback implementation of
is_convertible, which is used by GCC. Removing the "__is_convertible"
specializations for array/function types we fallback on the SFINAE test,
which is more correct.
See https://llvm.org/bugs/show_bug.cgi?id=27538
llvm-svn: 268359
Summary:
Replace non-Standard "atomic_flag f(false);" with Standard "atomic_flag f;" in clear tests.
Although the value of 'f' is unspecified it shouldn't matter because these tests always call `f.test_and_set()` without checking the result, so the initial state shouldn't matter.
The test init03.pass.cpp is explicitly testing this non-Standard extension; It has been moved into the `test/libcxx` directory.
Reviewers: mclow.lists, STL_MSFT
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19758
llvm-svn: 268355
std::__clz is a libc++ specific function so it can't be used in the test suite.
This patch implements a dumb "count leading zeros" implementation within
hexfloat itself.
This patch also fixes UB since the output of `__builtin_clz(0)` is undefined
according to the GCC docs.
llvm-svn: 268354
This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers.
llvm-svn: 268124
This patch does the following:
* Remove <__config> includes from some container tests.
* Guards uses of std::launch::any in async tests because it's an extension.
* Move "test/std/extensions" to "test/libcxx/extensions"
* Moves various non-standard tests including those in "sequences/vector",
"std/localization" and "utilities/meta".
llvm-svn: 267981
Testing the concrete implementation of INVOKE means calling the implementation
specific names `__invoke` and `__invoke_constexpr`. For this reason the test
are non-standard. For this reason it's best if the tests live outside of the
`test/std` directory.
llvm-svn: 267973
Summary:
when setting LIBCXX_ENABLE_EXCEPTIONS=false, _LIBCPP_NO_EXCEPTIONS wil be defined in both commandline and _config
Reviewers: bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19344
llvm-svn: 266956
Summary:
Hi,
When creating a new thread libc++ performs at least 2 allocations. The first allocates a tuple of args and the functor that will be passed to the new thread. The second allocation is for the thread local storage needed internally by libc++. Currently the second allocation happens in the child thread, meaning that if it throws the program will terminate with an uncaught bad alloc.
The solution to this is to allocate ALL memory in the parent thread and then pass it to the child.
See https://llvm.org/bugs/show_bug.cgi?id=15638
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13748
llvm-svn: 266851
The primary purpose of this patch is to add the 'is_callable' traits.
Since 'is_nothrow_callable' required making 'INVOKE' conditionally noexcept
I also took this oppertunity to implement a constexpr version of INVOKE.
This fixes 'std::experimental::apply' which required constexpr 'INVOKE support'.
This patch will be followed up with some cleanup. Primarly removing most
of "__member_function_traits" since it's no longer used by INVOKE (in C++11 at least).
llvm-svn: 266836
These changes make linking against static libraries more explicit. Instead
of using -lc++ and -lc++abi in the tests, an absolute path to the library is
provided instead.
The choices of shared vs. static, and the choices of library paths for both
libcxx and libcxxabi needed to be exchanged for this to work. In other words,
libcxx tests need to know the library path of libcxxabi, and whether libcxxabi
is a static or shared library.
Some Mac specific logic for testing against libc++abi had to be moved from
libcxxabi's config.py, as it was overriding choices made in libcxx's config.py.
That logic is now in libcxx's target_info.py.
Testing a static libcxx on Linux will now automatically link in librt most of
the time. Previously, lots of pthread tests would fail because of an
unresolved clock_gettime.
http://reviews.llvm.org/D16544
llvm-svn: 266730
In cases where emplace is called with two arguments and the first one
matches the key_type we can Key to check for duplicates before allocating.
This patch expands on work done by dexonsmith@apple.com.
llvm-svn: 266498
There are two main fixes in this patch.
First the constructor SFINAE was changed so that it's evaluated in two stages
where the first stage evaluates the "safe" SFINAE conditions and the second
evaluates the "dangerous" ones. The key is that the second stage is lazily
evaluated only if the first stage passes. This helps fix PR23256
(https://llvm.org/bugs/show_bug.cgi?id=23256).
The second fix is for PR22806 and LWG issue 2549. This fix applies
the suggested resolution to the LWG issue in order to prevent the construction
of dangling references. The SFINAE for this check is contained within
the _PreferTupleLikeConstructor alias template. The tuple-like constructors
are disabled whenever that trait returns false.
(https://llvm.org/bugs/show_bug.cgi?id=22806)
(http://cplusplus.github.io/LWG/lwg-active.html#2549)
llvm-svn: 266461
Summary:
A default uses-allocator constructor has been added since that overload was previously provided by the extended constructor.
Since Clang does implicit conversion checking after substitution this constructor has to deduce the allocator_arg_t parameter so that it can prevent the evaluation of "is_default_constructible" if the first argument doesn't match. See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1391 for more information.
This patch fixes PR24779 (https://llvm.org/bugs/show_bug.cgi?id=24779)
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19006
llvm-svn: 266409
map's allocator may only be used to construct objects of 'value_type',
or in this case 'pair<const Key, Value>'. In order to respect this requirement
in operator[], which requires default constructing the 'mapped_type', we have
to use pair's piecewise constructor with '(tuple<Kep>, tuple<>)'.
Unfortunately we still need to provide a fallback implementation for C++03
since we don't have <tuple>. Even worse this fallback is the last remaining
user of '__hash_map_node_destructor' and '__construct_node_with_key'.
This patch also switches try_emplace over to __tree.__emplace_unique_key_args.
llvm-svn: 264989
This patch is fairly large and contains a number of changes. The changes all work towards
allowing __tree to properly handle __value_type esspecially when inserting into the __tree.
I chose not to break this change into smaller patches because it wouldn't be possible to
write meaningful standard-compliant tests for each patch.
It is very similar to r260513 "[libcxx] Teach __hash_table how to handle unordered_map's __hash_value_type".
Changes in <map>
* Remove __value_type's constructors because it should never be constructed directly.
* Make map::emplace and multimap::emplace forward to __tree and remove the old definitions
* Remove "__construct_node" map and multimap member functions. Almost all of the construction is done within __tree.
* Fix map's move constructor to access "__value_type.__nc" directly and pass this object to __tree::insert.
Changes in <__tree>
* Add traits to detect, handle, and unwrap, map's "__value_type".
* Convert methods taking "value_type" to take "__container_value_type" instead. Previously these methods caused
unwanted implicit conversions from "std::pair<Key, Value>" to "__value_type<Key, Value>".
* Delete __tree_node and __tree_node_base's constructors and assignment operators. The node types should never be constructed
because the "__value_" member of __tree_node must be constructed directly by the allocator.
* Make the __tree_node_destructor class and "__construct_node" methods unwrap "__node_value_type" into "__container_value_type" before invoking the allocator. The user's allocator can only be used to construct and destroy the container's value_type. Passing it map's "__value_type" was incorrect.
* Cleanup the "__insert" and "__emplace" methods. Have __insert forward to an __emplace function wherever possible to reduce
code duplication. __insert_unique(value_type const&) and __insert_unique(value_type&&) forward to __emplace_unique_key_args.
These functions will not allocate a new node if the value is already in the tree.
* Change the __find* functions to take the "key_type" directly instead of passing in "value_type" and unwrapping the key later.
This change allows the find functions to be used without having to construct a "value_type" first. This allows for a number
of optimizations.
* Teach __move_assign and __assign_multi methods to unwrap map's __value_type.
llvm-svn: 264986
Summary:
This was voted into C++17 at the Jacksonville meeting. The final P0152R1
paper will be in the upcoming post-Jacksonville mailing, and is also
available here:
http://jfbastien.github.io/papers/P0152R1.html
Reviewers: mclow.lists, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17951
llvm-svn: 264413
unordered_set::emplace and unordered_map::emplace construct a node, then
try to insert it. If insertion fails, the node gets deleted.
To avoid this unnecessary malloc traffic, check to see if the argument
to emplace has the appropriate key_type. If so, we can use that key
directly and delay the malloc until we're sure we're inserting something
new.
Test updates by Eric Fiselier, who rewrote the old allocation tests to
include the new cases.
There are two orthogonal future directions:
1. Apply the same optimization to set and map.
2. Extend the optimization to when the argument is not key_type, but can
be converted to it without side effects. Ideally, we could do this
whenever key_type is trivially destructible and the argument is
trivially convertible to key_type, but in practise the relevant type
traits "blow up sometimes". At least, we should catch a few simple
cases (such as when both are primitive types).
llvm-svn: 263746
This adds clang thread safety annotations to std::mutex and
std::lock_guard so code using these types can use these types directly
instead of having to wrap the types to provide annotations. These checks
when enabled by -Wthread-safety provide simple but useful static
checking to detect potential race conditions.
See http://clang.llvm.org/docs/ThreadSafetyAnalysis.html for details.
This patch was reviewed in http://reviews.llvm.org/D14731.
llvm-svn: 263611
Commit f49839299a085505eb673544744b61d2d9cdd1db in glibc-2.14 changed the
locales to the currently required format. However, they were again changed in
commit 55bdd2866f23b28422d969060b3518909a12b100 which has been released in 2.17.
That leads to the current situation where Debian and e.g. CentOS 6 have the
pre-2.14 locales, for example Ubuntu 14.04 has pre-2.17 and CentOS 7 on the
other hand has the newest locales in glibc-2.17.
Differential Revision: http://reviews.llvm.org/D18187
llvm-svn: 263554
std::addressof may be used on a storage of an object before the start
of its lifetime (see std::allocate_shared for example). CFI flags the
C-style cast as invalid in that case.
llvm-svn: 263310
For the locale refactor, the locale management functions (newlocale,
freelocale, uselocale) are needed in a separate header from the various _l
functions. This is because some platforms implement the _l functions in terms
of a locale switcher RAII helper, and the locale switcher RAII helper needs
the locale management functions. This patch helps pave the way by getting all
the functions in the right files, so that later diffs aren't completely
horrible.
Unfortunately, the Windows, Cygwin, and MinGW builds seemed to have
bit-rotted, so I wasn't able to test this completely. I don't think I made
things any worse than they already are though.
http://reviews.llvm.org/D17419
llvm-svn: 263020
Instead of checking _LIBCPP_LOCALE_L_EXTENSIONS all over, instead check it
once, and define the various *_l symbols once. The private redirector symbol
names are all prefixed with _libcpp_* so that they won't conflict with user
symbols, and so they won't conflict with future C library symbols. In
particular, glibc likes providing private symbols such as __locale_t, so we
should follow a different naming pattern (like _libcpp_*) to avoid problems
on that front.
Tested on Linux with glibc. Hoping for the best on OSX and the various BSDs.
http://reviews.llvm.org/D17456
llvm-svn: 263016
The "const" pointer typedefs such as "__node_const_pointer" and
"__node_base_const_pointer" are identical to their non-const pointer types.
This patch changes all usages of "const" pointer type names to their respective
non-const typedef.
Since "fancy pointers to const" cannot be converted back to a non-const pointer
type according to the allocator requirements it is important that we never
actually use "const" pointers.
Furthermore since "__node_const_pointer" and "__node_pointer" already
name the same type, it's very confusing to use both names. Especially
when defining const/non-const overloads for member functions.
llvm-svn: 261419
This patch is very similar to r260431.
This patch is the first in a series of patches that's meant to better
support map. map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __tree about this
special value_type.
This patch creates a "__tree_node_types" traits class that contains
all of the typedefs needed by the associative containers and their iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "map"'s value type.
Although the associative containers already supported incomplete types, this
patch makes it official by adding tests.
This patch will be followed up shortly with various cleanups within __tree and
fixes for various map bugs and problems.
llvm-svn: 261416
Summary:
This bug was originally fixed in http://reviews.llvm.org/D7201.
However it was broken again by the fix to https://llvm.org/bugs/show_bug.cgi?id=22605.
This patch re-fixes __wrap_iter with GCC by providing a forward declaration of <vector> before the friend declaration in __wrap_iter.
This patch avoids the issues in PR22605 by putting canonical forward declarations in <iosfwd> and including <iosfwd> in <vector>.
<iosfwd> was chosen as the canonical forward declaration headers for the following reasons:
1. `<iosfwd>` is small with almost no dependancies.
2. It already forward declares `std::allocator`
3. It is already included in `<iterator>` which we need to fix the GCC bug.
This patch fixes the test "gcc_workaround.pass.cpp"
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16345
llvm-svn: 261382
Summary:
According to the C++ standard <stdbool.h> isn't allowed to define `true` `false` or `bool`. However these macros are sometimes defined by the compilers `stdbool.h`.
Clang defines the macros whenever `__STRICT_ANSI__` isn't defined (ie `-std=gnu++11`).
New GCC versions define the macros in C++03 mode only, older GCC versions (4.9 and before) always define the macros.
This patch adds a wrapper header for `stdbool.h` that undefs the required macros.
Reviewers: mclow.lists, rsmith, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16346
llvm-svn: 261381
This is one part of many of a locale refactor. See
http://reviews.llvm.org/D17146 for an idea of where this is going.
For the locale refactor, the locale management functions (newlocale,
freelocale, uselocale) are needed in a separate header from the various _l
functions. This is because some platforms implement the _l functions in terms
of a locale switcher RAII helper, and the locale switcher RAII helper needs
the locale management functions. This patch helps pave the way by getting all
the functions in the right files, so that later diffs aren't completely
horrible.
The "do-nothing" / "nop" locale functions are also useful on their own for
other lightweight platforms. Putting these nop implementations in
support/xlocale should enable code sharing.
Unfortunately, I have no access to a newlib system to build and test with, so
this change has been made blind.
Reviewed: http://reviews.llvm.org/D17382
llvm-svn: 261231
This is one part of many of a locale refactor. See
http://reviews.llvm.org/D17146 for an idea of where this is going.
For the locale refactor, the locale management functions (newlocale,
freelocale, uselocale) are needed in a separate header from the various _l
functions. This is because some platforms implement the _l functions in terms
of a locale switcher RAII helper, and the locale switcher RAII helper needs
the locale management functions. This patch helps pave the way by getting all
the functions in the right files, so that later diffs aren't completely
horrible.
Unfortunately, I have no access to an AIX machine to build with, so this change
has been made blind. Also, the original author (Xing Xue) does not appear to
have a Phabricator account.
Reviewed: http://reviews.llvm.org/D17380
llvm-svn: 261230
Marshall Clow