APInt: Make self-move-assignment a no-op to fix stage3 clang-cl

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
This commit is contained in:
Reid Kleckner
2014-08-12 22:01:39 +00:00
parent ee8b879822
commit 151f8cef74
2 changed files with 28 additions and 2 deletions

View File

@ -678,4 +678,21 @@ TEST(APIntTest, nearestLogBase2) {
EXPECT_EQ(A9.nearestLogBase2(), UINT32_MAX);
}
TEST(APIntTest, SelfMoveAssignment) {
APInt X(32, 0xdeadbeef);
X = std::move(X);
EXPECT_EQ(32, X.getBitWidth());
EXPECT_EQ(0xdeadbeefULL, X.getLimitedValue());
uint64_t Bits[] = {0xdeadbeefdeadbeefULL, 0xdeadbeefdeadbeefULL};
APInt Y(128, Bits);
Y = std::move(Y);
EXPECT_EQ(128, Y.getBitWidth());
EXPECT_EQ(~0ULL, Y.getLimitedValue());
const uint64_t *Raw = Y.getRawData();
EXPECT_EQ(2, Y.getNumWords());
EXPECT_EQ(0xdeadbeefdeadbeefULL, Raw[0]);
EXPECT_EQ(0xdeadbeefdeadbeefULL, Raw[1]);
}
}