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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276533 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276507 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276506 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276208 91177308-0d34-0410-b5e6-96231b3b80d8
The test I originally checked in only worked with ToT Clang. This patch
updates the test so that it works as far back as 3.5.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276093 91177308-0d34-0410-b5e6-96231b3b80d8
There is a bug in Clang's __is_constructible builtin that causes it
to return true for function types; ex [T = void()].
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276092 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276090 91177308-0d34-0410-b5e6-96231b3b80d8
The previous implementation relied highly on specializations to handle
special cases. This new implementation lets the compiler do the work when possible.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276084 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276078 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276067 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276049 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276003 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@275772 91177308-0d34-0410-b5e6-96231b3b80d8
