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.
llvm-svn: 134554
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.
llvm-svn: 115462
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.
llvm-svn: 112147
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.
llvm-svn: 102604
and there is a new SmallVectorTemplateBase class in between it and SmallVectorImpl.
SmallVectorTemplateBase can be specialized based on isPodLike.
llvm-svn: 91518
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.
llvm-svn: 91427
- 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.
llvm-svn: 79433
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.
llvm-svn: 72221
"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!
llvm-svn: 68277
heretical from a STL standpoint, but is oh-so-useful for things that
can't throw exceptions when copied, like, well, everything in LLVM.
llvm-svn: 60587
