Summary:
In the synopsis in C++11 subclause 28.8 [re.regex], `basic_regex` is
specified to have member typedefs `traits_type` and `string_type`. This
change adds them to libc++.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22698
Patch by Jason Liu!
llvm-svn: 277526
It currently fails because GCC changed the mangling of templates, which affects std::atomic using __attribute__((vector(X))). The bot using GCC 4.9 generates the following message:
In file included from /home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:24:0:
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic: In instantiation of 'atomic_test<T>::atomic_test() [with T = __vector(2) int]':
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:66:3: required from here
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: error: 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' conflicts with a previous declaration
__gcc_atomic_t() _NOEXCEPT = default;
^
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: previous declaration 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(1) int]'
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: -fabi-version=6 (or =0) avoids this error with a change in mangling
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: error: 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' conflicts with a previous declaration
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: previous declaration 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(1) int]'
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: -fabi-version=6 (or =0) avoids this error with a change in mangling
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:939:5: note: synthesized method 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' first required here
__atomic_base() _NOEXCEPT = default;
^
GCC's docs say the following about ABI version 6:
Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of C++11 scoped enums and the mangling of template argument packs, const/static_cast, prefix ++ and –, and a class scope function used as a template argument.
llvm-svn: 277380
Summary:
libc++ implements std::atomic<_Tp> using __atomic_base<_Tp> with
`mutable _Atomic(_Tp) __a_`. That member must be suitably aligned on
relevant ISAs for instructions such as cmpxchg to work properly, but
this alignment isn't checked anywhere. __atomic_base's implementation
relies on _Atomic doing "the right thing" since it's under the
compiler's control, and only the compiler knows about lock-freedom and
instruction generation. This test makes sure that the compiler isn't
breaking libc++'s expectations.
I'm looking at a few odd things in the C++ standard, and will have a few
other fixes around this area in the future.
This requires building with `-DLIBCXX_HAS_ATOMIC_LIB=True`, the test
marks the dependency as REQUIRES and won't be run without.
Reviewers: cfe-commits
Subscribers: EricWF, mclow.lists
Differential Revision: http://reviews.llvm.org/D22073
llvm-svn: 277368
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
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
In C++03 mode evaluating the SFINAE can cause a hard error due to
access control violations. This is a problem because the SFINAE
is evaluated as soon as the class is instantiated, and not later.
llvm-svn: 276594
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
There is a bug in Clang 3.6 and earlier that causes compile failures.
I suspect it's due to the usage of member function parameter names in the
attributes.
llvm-svn: 276507
Summary:
This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.
In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message.
Reviewers: mclow.lists, rsmith, jfb, EricWF
Subscribers: bcraig, jfb, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22557
llvm-svn: 276506
Increasingly the .fail.cpp tests are written using -verify, making them
sensitive to the exact diagnostics generated by the compiler. To prevent
additional diagnostics from being generated, and causing the tests to fail,
this patch removes the warning flags when compiling those tests.
llvm-svn: 276208
Although inheriting constructors have already been fixed in Clang 3.9 I still
choose to fix std::function so users can derive from it with older compilers.
llvm-svn: 276090
The previous implementation relied highly on specializations to handle
special cases. This new implementation lets the compiler do the work when possible.
llvm-svn: 276084
Libc++ provides static assertions to detect reference binding issues inside
tuple. This patch adds tests for those diagnostics.
It should be noted that these static assertions technically violate the
standard since it allows these illegal bindings to occur.
Also see https://llvm.org/bugs/show_bug.cgi?id=20855
llvm-svn: 276078
The functions arg, conj, imag, norm, proj, and real have additional overloads
for arguments of integral or floating point types. However these overloads should
not allow conversions to the integral/floating point types, only exact matches.
This patch constrains these functions so they no longer allow conversions.
llvm-svn: 276067
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
Summary:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.
* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.
Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.
To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.
The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`. Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.
To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.
Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.
The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.
Please let me know what you think.
Reviewers: howard.hinnant, mclow.lists
Subscribers: howard.hinnant, bbannier, cfe-commits
Differential Revision: https://reviews.llvm.org/D20786
llvm-svn: 276003
Constructing a std::locale object from an empty string selects the language
from the current environment variables. If the environment variables name
a locale that doesn't exist, or isn't installed, then the construction of
facets using that locale may throw.
This patch removes tests that use 'std::locale l("")'.
The optimal solution would be to manually set the environment variables
in the test. Unfortunately there is no portable way to do this.
llvm-svn: 275772
man page for mkdir says: "If the parent directory has the set-group-ID bit set,
then so will the newly created directory."
Differential Revision: https://reviews.llvm.org/D22265
llvm-svn: 275760
This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.
Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
test suite.
llvm-svn: 275759
This patch does the following:
* It renames `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` to `_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR`.
* It automatically enables this option on FreeBSD in ABI V1, since that's the current ABI FreeBSD ships.
* It cleans up the handling of this option in `std::pair`.
I would like the sign off from the FreeBSD maintainers. They will no longer need to keep their `__config` changes downstream.
I'm still hoping to come up with a better way to maintain the ABI without needing these constructors.
Reviewed in https://reviews.llvm.org/D21329
llvm-svn: 275749
This patch upgrades <tuple> to be C++17 compliant by implementing:
* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.
llvm-svn: 275745
This patch implements a simple optimization in __hash_table::find. When iterating
the found bucket we only constrain the bucket elements hash if it doesn't
already match the unconstrained hash of the specified key. This prevent
the performance of an expensive modulo operation.
Since the bucket element almost always matches the key, especially when the
load factor is low, this optimization has large performance impacts. For
a unordered_set<int> of random integers this patch improves the performance of
'find(...)' by 40%.
llvm-svn: 275734
From r229162:
Visual Studio's SAL extension uses a macro named __deallocate. This
macro is used pervasively
Using -Werror when building for Windows can force the use of -Wno-#warnings
specifically because of this __deallocate #warning. Instead of forcing
builds to disable all #warnings, this option allows libc++ to be built
without this particular warning, while leaving other #warnings enabled.
Patch by Dave Lee!
llvm-svn: 275172
This cleans up a previous optimization attempt in hash, and results in
additional performance improvements over that previous attempt. Additionally
this new optimization does not hinder the power of 2 bucket count optimization.
llvm-svn: 275114
Summary: The current implementations of __hash_table::find used by std::unordered_set/unordered_map call key_eq on each key that lands in the same bucket as the key you're looking for. However, since equal objects mush hash to the same value, you can short-circuit the possibly expensive call to key_eq by checking the hashes first.
Reviewers: EricWF
Subscribers: kmensah, cfe-commits
Differential Revision: http://reviews.llvm.org/D21510
llvm-svn: 274857
This patch improves the performance of unordered_set's find by 45% when
the value exists within the set. __hash_tables find method
needs to check if it's reached the end of the bucket by constraining the
hash of the current node and checking it against the bucket index. However
constraining the hash is an expensive operations and it can be avoided if the
two unconstrained hashes are equal. This patch applies that optimization.
This patch also adds a top level directory called benchmarks. 'benchmarks/'
is intended to store any/all benchmarks written for the standard library.
Currently nothing is done with files under 'benchmarks/' but I would like
to move towards introducing a formal format and test runner.
llvm-svn: 274423
This patch is the last in a series that replaces recursive meta-programming
in std::tuple with non-recursive implementations.
Previously std::tuple could only be instantiated with 126 elements before
it blew the max template instantiation depth. Now the size of std::tuple is
essentially unbounded (I've tested with over 5000 elements).
One unfortunate side-effect of this change is that tuple_constructible
and similar no longer short circuit after the first failure. Instead they
evaluate the conditions for all elements. This could be potentially breaking.
I plan to look into this further.
llvm-svn: 274331
This patch attempts to improve the QoI of std::tuples tuple_element and
__make_tuple_types helpers. Previously they required O(N) instantiations,
one for every element in the tuple
The new implementations are O(1) after __tuple_indices<Id...> is created.
llvm-svn: 274330
The previous __make_tuple_indices implementation caused O(N) instantiations
and was pretty inefficient. The C++14 __make_integer_sequence implementation
is much better, since it either uses a builtin to generate the sequence or
a very nice Log8(N) implementation provided by richard smith.
This patch moves the __make_integer_sequence implementation into __tuple
and uses it to implement __make_tuple_indices.
Since libc++ can't expose the name 'integer_sequence' in C++11 this patch
also introduces a dummy type '__integer_sequence' which is used when generating
the sequence. One the sequence is generated '__integer_sequence' can be
converted into the required type; either '__tuple_indices' or 'integer_sequence'.
llvm-svn: 274286
* P0163r0: Implemented in r273839.
* LWG 2309: pthread_mutex_lock only returns this error if certain debug flags
were passed during construction. libc++ does not pass these flags. There is
nothing to do.
* LWG 2310: Wording fix. No impact on libc++'s implementation.
* LWG 2312: libc++'s std::tuple implementation already constrains the overloads
based on the number of arguments.
* LWG 2549: libc++'s std::tuple already applied this fix.
* LWG 2674: libc++ already depends on this relaxed wording.
* LWG 2704, 2706, 2707, 2719, 2720, 2721, 2723, 2725, 2728: All of these filesystem were either
submitted by me and fixed before submission, or have already been applied.
llvm-svn: 274214
Since at least the C++11 standard insert iterators are specified
as having ::reference typedef void. Libc++ was not doing that.
This patch corrects the typedef.
This patch changes the std::iterator base class of insert_iterator,
front_insert_iterator and back_insert_iterator. This should not
be an ABI breaking change.
llvm-svn: 274209
The end pointer should point to one past the end of the newly allocated
buffer.
rdar://problem/24265174
Differential Revision: http://reviews.llvm.org/D20334
llvm-svn: 274132
This patch adds the weak_type typedef in shared_ptr. It is available in
C++17 and newer.
This patch also updates the _LIBCPP_STD_VER and TEST_STD_VER macros to
have the value of 16, since 2016 is the current year.
llvm-svn: 273839
See https://llvm.org/bugs/show_bug.cgi?id=27115
The problem was that the conversion from
'const enable_shared_from_this<T>*' to 'const T*' didn't work if
T inherited enable_shared_from_this as a virtual base class. The fix
is to take the original pointer passed to shared_ptr's constructor in the
__enable_weak_this method and perform an upcast to 'const T*' instead of
performing a downcast from the enable_shared_from_this base.
llvm-svn: 273835
The move constructor for wstring_convert accidentally copied the state member
into the converted count member in the move constructor. This patch fixes
the typo.
While working on this I discovered that wstring_convert doesn't actually
provide a move constructor according to the standard and therefore this
constructor is a libc++ extension. I'll look further into whether libc++ should
provide this constructor at all. Neither libstdc++ or MSVC's STL provide it.
llvm-svn: 273831
Hubert Tong