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
heretical from a STL standpoint, but is oh-so-useful for things that
can't throw exceptions when copied, like, well, everything in LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60587 91177308-0d34-0410-b5e6-96231b3b80d8
copies of a value, and add several additional utilities to make
SmallVector better conform to the Container concept.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57616 91177308-0d34-0410-b5e6-96231b3b80d8
handled correctly, and change a few SmallVector uses to use
size 0 to more clearly reflect their intent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55181 91177308-0d34-0410-b5e6-96231b3b80d8
conversion open the door for many nasty implicit conversion issues, and
can be easily solved by initializing with (V.begin(), V.end()) when
needed.
This patch includes many small cleanups for sdisel also.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50340 91177308-0d34-0410-b5e6-96231b3b80d8
don't access cached iterators from after the erased element.
Re-apply 49056 with SmallVector support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49106 91177308-0d34-0410-b5e6-96231b3b80d8
