bcm5719-llvm/libcxx/include/vector, branch meklort-10.0.1

[libc++] Rework compressed pair constructors.

2019-12-16T23:38:58+00:00

This patch de-duplicates most compressed pair constructors to use the same code in C++11 and C++03. Part of doing that is deleting the "__second_tag()" and replacing it with a "__value_init_tag()" which has the same effect, but allows for the removal of the special "one-arg" first element constructor. This patch is intended to have no semantic change.

Rename __is_foo_iterator traits to reflect their Cpp17 nature.

2019-11-18T06:49:32+00:00

With the upcoming introduction of iterator concepts in ranges, the meaning of "__is_contiguous_iterator" changes drastically. Currently we intend it to mean "does it have this iterator category", but it could now also mean "does it meet the requirements of this concept", and these can be different.

[libc++] Rename __to_raw_pointer to __to_address.

2019-11-16T22:16:09+00:00

This function has the same behavior as the now-standand std::to_address. Re-using the name makes the behavior more clear, and in the future it will allow us to correctly get the raw pointer for user provided pointer types.

Recommit r370502: Make `vector` unconditionally move elements when

2019-09-13T16:09:33+00:00

exceptions are disabled. The patch was reverted due to some confusion about non-movable types. ie types that explicitly delete their move constructors. However, such types do not meet the requirement for `MoveConstructible`, which is required by `std::vector`: Summary: `std::vector` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying. This patch makes `std::vector` unconditionally move elements when exceptions are disabled. This optimization is conforming according to the current standard wording. There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization. Reviewers: mclow.lists, ldionne, rsmith Reviewed By: ldionne Subscribers: zoecarver, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62228 llvm-svn: 371867

[libc++] Revert "Make `vector` unconditionally move elements when exceptions are disabled."

2019-09-05T13:50:28+00:00

This reverts r370502, which broke the use case of a copy-only T (with a deleted move constructor) when exceptions are disabled. Until we figure out the right behavior, I'm reverting the commit. llvm-svn: 371068

Make `vector` unconditionally move elements when exceptions are disabled.

2019-08-30T19:01:03+00:00

Summary: `std::vector` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying. This patch makes `std::vector` unconditionally move elements when exceptions are disabled. This optimization is conforming according to the current standard wording. There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization. Reviewers: mclow.lists, ldionne, rsmith Reviewed By: ldionne Subscribers: zoecarver, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62228 llvm-svn: 370502

[libc++] Fix visibility of __vector_base_common on GCC

2019-08-28T18:10:39+00:00

Since we build the library with -fvisibility=hidden, the shared object wouldn't contain __vector_base_common::__throw_length_error() and __vector_base_common::__throw_out_of_range(), leading to link errors. This only happened on GCC for some reason. https://llvm.org/PR43140 llvm-svn: 370240

Fix PR35637: suboptimal codegen for `vector`.

2019-07-28T04:37:02+00:00

The optimizer is petulant and temperamental. In this case LLVM failed to lower the the "insert at end" loop used by`vector` to a `memset` despite `memset` being substantially faster over a range of bytes. LLVM has the ability to lower loops to `memset` whet appropriate, but the odd nature of libc++'s loops prevented the optimization from taking places. This patch addresses the issue by rewriting the loops from the form `do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer range (For example: `for (auto *__i = ...; __i < __e; ++__i)`). This patch also rewrites the asan annotations to unposion all additional memory at the start of the loop instead of once per iterations. This could potentially permit false negatives where the constructor of element N attempts to access element N + 1 during its construction. The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean` benchmark (run 5 times) are: -------------------------------------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------------------------------------- Before ------ BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5 ----- After ----- BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5 llvm-svn: 367183

Add visibility attributes and inline to some vector methods.

2019-03-19T19:19:44+00:00

Adding filesystem to the dylib caused some vector symbols to leak into the set of exported symbols. This patch hides those symbols. llvm-svn: 356502

Remove exception throwing debug mode handler support.

2019-03-18T21:50:12+00:00

Summary: The reason libc++ implemented a throwing debug mode handler was for ease of testing. Specifically, I thought that if a debug violation aborted, we could only test one violation per file. This made it impossible to test debug mode. Which throwing behavior we could test more! However, the throwing approach didn't work either, since there are debug violations underneath noexcept functions. This lead to the introduction of `_NOEXCEPT_DEBUG`, which was only noexcept when debug mode was off. Having thought more and having grown wiser, `_NOEXCEPT_DEBUG` was a horrible decision. It was viral, it didn't cover all the cases it needed to, and it was observable to the user -- at worst changing the behavior of their program. This patch removes the throwing debug handler, and rewrites the debug tests using 'fork-ing' style death tests. Reviewers: mclow.lists, ldionne, thomasanderson Reviewed By: ldionne Subscribers: christof, arphaman, libcxx-commits, #libc Differential Revision: https://reviews.llvm.org/D59166 llvm-svn: 356417