handles with a pointer to the containing map. When a map is copied, these
pointers need to be corrected to point to the new map. If not, then consider
the case of a map M1 which maps a value V to something. Create a copy M2 of
M1. At this point there are two value handles on V, one representing V as a
key in M1, the other representing V as a key in M2. But both value handles
point to M1 as the containing map. Now delete V. The value handles remove
themselves from their containing map (which destroys them), but only the first
value handle is successful: the second one cannot remove itself from M1 as
(once the first one has removed itself) there is nothing there to remove; it
is therefore not destroyed. This causes an assertion failure "All references
to V were not removed?".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109851 91177308-0d34-0410-b5e6-96231b3b80d8
EXPECT_{TRUE,FALSE}(...) macros. This also prevents suprious warnings about
bool-to-pointer conversion that occurs withit EXPECT_EQ.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108248 91177308-0d34-0410-b5e6-96231b3b80d8
- This can give substantial speedups in the delta process for inputs we can construct dependency information for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105612 91177308-0d34-0410-b5e6-96231b3b80d8
This means that our Registers are now ordered R7, R8, R9, R10, R12, ...
Not R1, R10, R11, R12, R2, R3, ...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104745 91177308-0d34-0410-b5e6-96231b3b80d8
- This provides a convenient alternative to using something llvm::prior or
manual iterator access, for example::
if (T *Prev = foo->getPrevNode())
...
instead of::
iterator it(foo);
if (it != begin()) {
--it;
...
}
- Chris, please review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103647 91177308-0d34-0410-b5e6-96231b3b80d8
payloads. APFloat's internal folding routines always make QNaNs now,
instead of sometimes making QNaNs and sometimes SNaNs depending on the
type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97364 91177308-0d34-0410-b5e6-96231b3b80d8
It fails with a release build only, for reasons
as yet unknown. (If there's a better way to Xfail
things here let me know, doesn't seem to be any
prior art in unittests.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95700 91177308-0d34-0410-b5e6-96231b3b80d8
a single pointer (PointerIntPair) member. In "small" mode, the
pointer field is reinterpreted as a set of bits. In "large" mode,
the pointer points to a heap-allocated object.
Also, give BitVector empty and swap functions.
And, add some simple unittests for BitVector and SmallBitVector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92730 91177308-0d34-0410-b5e6-96231b3b80d8
will be found by argument-dependent lookup. As with the previous
commit, GCC is allowing ill-formed code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92146 91177308-0d34-0410-b5e6-96231b3b80d8
argument-dependent lookup can find it. This is another case where an
LLVM bug (not making operator<< visible) was masked by a GCC bug
(looking in the global namespace when it shouldn't).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92144 91177308-0d34-0410-b5e6-96231b3b80d8
smallest-normalized-magnitude values in a given FP semantics.
Provide an APFloat-to-string conversion which I am quite ready to admit could
be much more efficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92126 91177308-0d34-0410-b5e6-96231b3b80d8
- This is a pretty slow / memory intensive implementation, and I will likely
change it to an iterative model, but it works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90447 91177308-0d34-0410-b5e6-96231b3b80d8
This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.
The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.
Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.
Patch by Victor Zverovich!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86636 91177308-0d34-0410-b5e6-96231b3b80d8
even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.
It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84890 91177308-0d34-0410-b5e6-96231b3b80d8
