It always returns the iterator for the first inserted element, or the passed in
iterator if the inserted range was empty. Flesh out the unit test more and fix
all the cases it uncovered so far.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158645 91177308-0d34-0410-b5e6-96231b3b80d8
Note that support for rvalue references does not imply support
for the full set of move-related STL operations.
I've preserved support for an odd little thing in insert() where
we're trying to support inserting a new element from an existing
one. If we actually want to support that, there's a lot more we
need to do: insert can call either grow or push_back, neither of
which is safe against this particular use pattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155979 91177308-0d34-0410-b5e6-96231b3b80d8
vec.insert(vec.begin(), vec[3]);
The issue was that vec[3] returns a reference into the vector, which is invalidated when insert() memmove's the elements down to make space. The method needs to specifically detect and handle this case to correctly match std::vector's semantics.
Thanks to Howard Hinnant for clarifying the correct behavior, and explaining how std::vector solves this problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134554 91177308-0d34-0410-b5e6-96231b3b80d8
is partly because this attribute caused trouble in the past (the
SmallVector one had to be changed from aligned to aligned(8) due
to causing crashes on i386 for example; in theory the same might
be needed in the Allocator case...). But it's mostly because
there seems to be no point in special casing gcc here. Using the
same implementation for all compilers results in better testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115462 91177308-0d34-0410-b5e6-96231b3b80d8
capacity and remove the workaround in SmallVector<T,0>. There are some
theoretical benefits to a N->2N+1 growth policy anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112870 91177308-0d34-0410-b5e6-96231b3b80d8
I think there are good reasons to change this, but in the interests
of short-term stability, make SmallVector<...,0> reserve non-zero
capacity in its constructors. This means that SmallVector<...,0>
uses more memory than SmallVector<...,1> and should really only be
used (unless/until this workaround is removed) by clients that
care about using SmallVector with an incomplete type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112147 91177308-0d34-0410-b5e6-96231b3b80d8
Limit alignment in SmallVector 8, otherwise GCC assumes 16 byte alignment.
opetaror new, and malloc only return 8-byte aligned memory on 32-bit Linux,
which cause a crash if code is compiled with -O3 (or -ftree-vectorize) and some
SmallVector code is vectorized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102604 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't apply to the type, only to the variable, so subsequent uses
of U which expect it to be aligned weren't actually aligned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98843 91177308-0d34-0410-b5e6-96231b3b80d8
SmallVectorTemplateBase class, which allows us to statically
dispatch on isPodLike instead of dynamically.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91523 91177308-0d34-0410-b5e6-96231b3b80d8
down into SmallVectorImpl. This requires sprinking a ton of this->'s in,
but gives us a place to factor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91522 91177308-0d34-0410-b5e6-96231b3b80d8
and there is a new SmallVectorTemplateBase class in between it and SmallVectorImpl.
SmallVectorTemplateBase can be specialized based on isPodLike.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91518 91177308-0d34-0410-b5e6-96231b3b80d8
1. Use std::equal instead of reinventing it.
2. don't run dtors in destroy_range if element is pod-like.
3. Use isPodLike to decide between memcpy/uninitialized_copy
instead of is_class. isPodLike is more generous in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91427 91177308-0d34-0410-b5e6-96231b3b80d8
- These allow clients to make use of the extra elements in the vector which
have already been allocated, without requiring them to be value initialized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79433 91177308-0d34-0410-b5e6-96231b3b80d8
If this causes any new assertion failures that I didn't catch in
testing, the fix is usually to change "&v[0]" to "v.data()" for some
SmallVector v.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72221 91177308-0d34-0410-b5e6-96231b3b80d8
"The code was doing "if (End+NumInputs > Capacity) ...". If End is
close to 0xFFFFFFFF and NumInputs is large, it'll overflow, the
condition will come out false, and the vector won't grow to
accommodate the new elements, and the program will crash in memmove."
Patch by Jeffrey Yasskin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68277 91177308-0d34-0410-b5e6-96231b3b80d8
