It's not clear what the semantics of a self-move should be. The
consensus appears to be that a self-move should leave the object in a
moved-from state, which is what our existing move assignment operator
does.
However, the MSVC 2013 STL will perform self-moves in some cases. In
particular, when doing a std::stable_sort of an already sorted APSInt
vector of an appropriate size, one of the merge steps will self-move
half of the elements.
We don't notice this when building with MSVC, because MSVC will not
synthesize the move assignment operator for APSInt. Presumably MSVC
does this because APInt, the base class, has user-declared special
members that implicitly delete move special members. Instead, MSVC
selects the copy-assign operator, which defends against self-assignment.
Clang, on the other hand, selects the move-assign operator, and we get
garbage APInts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215478 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the MinGW32 and Cygwin types from the OSType enumeration. These values
are represented via environments of Windows. It is a source of confusion and
needlessly clutters the code. The cost of doing this is that we must sink the
check for them into the normalization code path along with the spelling.
Addresses PR20592.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215303 91177308-0d34-0410-b5e6-96231b3b80d8
checking whether the ArrayRef is equal to an explicit list of arguments.
This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.
Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214041 91177308-0d34-0410-b5e6-96231b3b80d8
Add a `MapVector::remove_if()` that erases items in bulk in linear time,
as opposed to quadratic time for repeated calls to `MapVector::erase()`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213090 91177308-0d34-0410-b5e6-96231b3b80d8
Actually update the changed indexes in the map portion of `MapVector`
when erasing from the middle. Add a unit test that checks for this.
Note that `MapVector::erase()` is a linear time operation (it was and
still is). I'll commit a new method in a moment called
`MapVector::remove_if()` that deletes multiple entries in linear time,
which should be slightly less painful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213084 91177308-0d34-0410-b5e6-96231b3b80d8
The slice(N, M) interface is powerful but not concise when wanting to
drop a few elements off of an ArrayRef, fix this by adding a drop_back
method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212370 91177308-0d34-0410-b5e6-96231b3b80d8
Certain versions of GCC (~4.7) couldn't handle the SFINAE on access
control, but with "= delete" (hidden behind a macro for portability)
this issue is worked around/addressed.
Patch by Agustín Bergé
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211525 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately there's no way to elegantly do this with pre-canned
algorithms. Using a generating iterator doesn't work because you default
construct for each element, then move construct into the actual slot
(bad for copy but non-movable types, and a little unneeded overhead even
in the move-only case), so just write it out manually.
This solution isn't exception safe (if one of the element's ctors calls
we don't fall back, destroy the constructed elements, and throw on -
which std::uninitialized_fill does do) but SmallVector (and LLVM) isn't
exception safe anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210495 91177308-0d34-0410-b5e6-96231b3b80d8
To test cases that involve actual repetition (> 1 elements), at least
one element before the insertion point, and some elements of the
original range that still fit in that range space after insertion.
Actually we need coverage for the inverse case too (where no elements
after the insertion point fit into the previously allocated space), but
this'll do for now, and I might end up rewriting bits of SmallVector to
avoid that special case anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210436 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically this caused inserting an element from a SmallVector into
itself when such an insertion would cause a reallocation. We have code
to handle this for non-reallocating cases, but it's not robust against
reallocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210430 91177308-0d34-0410-b5e6-96231b3b80d8
(& because it makes it easier to test, this also improves
correctness/performance slightly by moving the last element in an insert
operation, rather than copying it)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210429 91177308-0d34-0410-b5e6-96231b3b80d8
Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike most FP ops) *does* attach semantic meaning to the signbit of NaN.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210428 91177308-0d34-0410-b5e6-96231b3b80d8
This would cause the last element in a range to be in a moved-from state
after an insert at a non-end position, losing that value entirely in the
process.
Side note: move_backward is subtle. It copies [A, B) to C-1 and down.
(the fact that it decrements both the second and third iterators before
the first movement is the subtle part... kind of surprising, anyway)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210426 91177308-0d34-0410-b5e6-96231b3b80d8
When we were moving from a larger vector to a smaller one but didn't
need to re-allocate, we would move-assign over uninitialized memory in
the target, then move-construct that same data again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207663 91177308-0d34-0410-b5e6-96231b3b80d8
never actually compared for equality two pointer unions that were equal.
Fortunately, things seem to work. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207468 91177308-0d34-0410-b5e6-96231b3b80d8
It's fishy to be changing the `std::vector<>` owned by the iterator, and
no one actual does it, so I'm going to remove the ability in a
subsequent commit. First, update the users.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207252 91177308-0d34-0410-b5e6-96231b3b80d8
This generalises the object file type parsing to all Windows environments. This
is used by cygwin as well as MSVC environments for MCJIT. This also makes the
triple more similar to Chandler's suggestion of a separate field for the object
file format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205219 91177308-0d34-0410-b5e6-96231b3b80d8
This is causing the ARM build-bots to fail since they only include
the ARM backend and can't create an ARM64 target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205132 91177308-0d34-0410-b5e6-96231b3b80d8
If the environment is unknown and no object file is provided, then assume an
"MSVC" environment, otherwise, set the environment to the object file format.
In the case that we have a known environment but a non-native file format for
Windows (COFF) which is used for MCJIT, then append the custom file format to
the triple as an additional component.
This fixes the MCJIT tests on Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205130 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205090 91177308-0d34-0410-b5e6-96231b3b80d8
Construct a uniform Windows target triple nomenclature which is congruent to the
Linux counterpart. The old triples are normalised to the new canonical form.
This cleans up the long-standing issue of odd naming for various Windows
environments.
There are four different environments on Windows:
MSVC: The MS ABI, MSVCRT environment as defined by Microsoft
GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries
Itanium: The MSVCRT environment + libc++ built with Itanium ABI
Cygnus: The Cygwin environment which uses custom libraries for everything
The following spellings are now written as:
i686-pc-win32 => i686-pc-windows-msvc
i686-pc-mingw32 => i686-pc-windows-gnu
i686-pc-cygwin => i686-pc-windows-cygnus
This should be sufficiently flexible to allow us to target other windows
environments in the future as necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204977 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r203374.
Ambiguities in assign... oh well. I'm just going to revert this and
probably not try to recommit it as it's not terribly important.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203375 91177308-0d34-0410-b5e6-96231b3b80d8
Move a common utility (assign(iter, iter)) into SmallVector (some of the
others could be moved there too, but this one seemed particularly
generic) and replace repetitions overrides with using directives.
And simplify SmallVector::assign(num, element) while I'm here rather
than thrashing these files (that cause everyone to rebuild) again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203374 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the assertions in PointerIntPair would try to calculate the value
(1 << NumLowBitsAvailable); the inferred type here is 'int', so if there were
more than 31 bits available we'd get a shift overflow.
Also, add a rudimentary unit test file for PointerIntPair.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203273 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preliminary setup change to support a renaming of Windows target
triples. Split the object file format information out of the environment into a
separate entity. Unfortunately, file format was previously treated as an
environment with an unknown OS. This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203160 91177308-0d34-0410-b5e6-96231b3b80d8
The interaction between defaulted operators and move elision isn't
totally obvious, add a unit test so it doesn't break unintentionally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202662 91177308-0d34-0410-b5e6-96231b3b80d8
it interoperate (minimally) with std::unique_ptr<T>. This is part of my
plan to migrate LLVM to use std::unique_ptr with a minimal impact on
out-of-tree code.
Patch by Ahmed Charles with some minor cleanups (and bool casts) by me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202608 91177308-0d34-0410-b5e6-96231b3b80d8
Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202206 91177308-0d34-0410-b5e6-96231b3b80d8
In theory, Clang should figure out how to parse this correctly without
typename, but since this is the last TU that Clang falls back on in the
self-host, I'm going to compromise and check for __clang__.
And now Clang can self-host on -win32 without fallback! The 'check' and
'check-clang' targets both pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201358 91177308-0d34-0410-b5e6-96231b3b80d8
Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:
StringRef myCopy = myStr.copy(myAllocator);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200885 91177308-0d34-0410-b5e6-96231b3b80d8
There are a couple of interesting things here that we want to check over
(particularly the expecting asserts in StringRef) and get right for general use
in ADT so hold back on this one. For clang we have a workable templated
solution to use in the meanwhile.
This reverts commit r200187.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200194 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr
expression as well as a runtime assert or compiler hint in release builds. This
technique can be used to construct functions that are both unevaluated and
compiled depending on usage.
(2) Update StringRef using llvm_expect() to preserve runtime assertions while
extending the same checks to static asserts in C++11 builds that support the
feature.
(3) Introduce ConstStringRef, a strong subclass of StringRef that references
compile-time constant strings. It's convertible to, but not from, ordinary
StringRef and thus can be used to add compile-time safety to various interfaces
in LLVM and clang that only accept fixed inputs such as diagnostic format
strings that tend to get misused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200187 91177308-0d34-0410-b5e6-96231b3b80d8
This was due to arithmetic overflow in the getNumBits() computation. Now we
cast BitWidth to a uint64_t so that does not occur during the computation. After
the computation is complete, the uint64_t is truncated when the function
returns.
I know that this is not something that is likely to happen, but it *IS* a valid
input and we should not blow up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199609 91177308-0d34-0410-b5e6-96231b3b80d8
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
This functionality was enabled by r198374. Here's a test to ensure it
works and we don't regress it.
Based on a patch by Maciej Piechotka.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198377 91177308-0d34-0410-b5e6-96231b3b80d8
Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful
option and can give surprising results (like tail calls being disabled).
5.0 seems like a reasonable compromise as a platform that's still interesting
to some people.
rdar://problem/15567348
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196912 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance the tests to actually require moves in C++11 mode, in addition
to testing the moved-from state. Further enhance the tests to cover
copy-assignment into a moved-from object and moving a large-state
object. (Note that we can't really test small-state vs. large-state as
that isn't an observable property of the API really.) This should finish
addressing review on r195239.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195261 91177308-0d34-0410-b5e6-96231b3b80d8
r195239, as well as a comment about the fact that assigning over
a moved-from object was in fact tested. Addresses some of the review
feedback on r195239.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195260 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.
The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195239 91177308-0d34-0410-b5e6-96231b3b80d8
This patch places class definitions in implementation files into anonymous
namespaces to prevent weak vtables. This eliminates the need of providing an
out-of-line definition to pin the vtable explicitly to the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195092 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
This bug only bit the C++98 build bots because all of the actual uses
really do move. ;] But not *quite* ready to do the whole C++11 switch
yet, so clean it up. Also add a unit test that catches this immediately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194548 91177308-0d34-0410-b5e6-96231b3b80d8
r-value references. I still want to test that when we have them,
llvm_move is actually a move.
Have I mentioned that I really want to move to C++11? ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194318 91177308-0d34-0410-b5e6-96231b3b80d8
Clang managed to never instantiate the copy constructor. Added tests to
ensure this path is tested.
We could still use tests for the polymorphic nature. Those coming up
next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194317 91177308-0d34-0410-b5e6-96231b3b80d8
unique ownership smart pointer which is *deep* copyable by assuming it
can call a T::clone() method to allocate a copy of the owned data.
This is mostly useful with containers or other collections of uniquely
owned data in C++98 where they *might* copy. With C++11 we can likely
remove this in favor of move-only types and containers wrapped around
those types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194315 91177308-0d34-0410-b5e6-96231b3b80d8
This is a re-commit of r189442; I'll follow up with clang changes.
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189624 91177308-0d34-0410-b5e6-96231b3b80d8
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189442 91177308-0d34-0410-b5e6-96231b3b80d8
