| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
until other LLVM projects using these are cleaned up.
llvm-svn: 117200
|
| |
|
|
|
|
| |
to link in "core".
llvm-svn: 114831
|
| |
|
|
| |
llvm-svn: 114830
|
| |
|
|
|
|
| |
Cameron Esfahani, tweaked to use array_lengthof.
llvm-svn: 114073
|
| |
|
|
|
|
|
|
| |
miscompiled by the system gcc-4.2.1
The test remains enabled for the second-stage test.
llvm-svn: 113824
|
| |
|
|
|
|
| |
characters > 127.
llvm-svn: 112189
|
| |
|
|
|
|
| |
consistent with compare in corner cases.
llvm-svn: 112185
|
| |
|
|
| |
llvm-svn: 111539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target triple and straightens it out. This does less than gcc's script
config.sub, for example it turns i386-mingw32 into i386--mingw32 not
i386-pc-mingw32, but it does a decent job of turning funky triples into
something that the rest of the Triple class can understand. The plan
is to use this to canonicalize triple's when they are first provided
by users, and have the rest of LLVM only deal with canonical triples.
Once this is done the special case workarounds in the Triple constructor
can be removed, making the class more regular and easier to use. The
comments and unittests for the Triple class are already adjusted in this
patch appropriately for this brave new world of increased uniformity.
llvm-svn: 110909
|
| |
|
|
|
|
|
| |
and removing it catches the mistake of passing a ValueMap by
copy rather than by reference.
llvm-svn: 110549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?".
llvm-svn: 109851
|
| |
|
|
|
|
|
| |
EXPECT_{TRUE,FALSE}(...) macros. This also prevents suprious warnings about
bool-to-pointer conversion that occurs withit EXPECT_EQ.
llvm-svn: 108248
|
| |
|
|
| |
llvm-svn: 108048
|
| |
|
|
|
|
|
|
| |
top of the standard 'delta debugging' algorithm.
- This can give substantial speedups in the delta process for inputs we can construct dependency information for.
llvm-svn: 105612
|
| |
|
|
|
|
|
| |
This means that our Registers are now ordered R7, R8, R9, R10, R12, ...
Not R1, R10, R11, R12, R2, R3, ...
llvm-svn: 104745
|
| |
|
|
| |
llvm-svn: 103723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
llvm-svn: 103647
|
| |
|
|
|
|
| |
and fix a bug in BitVector's reference proxy class which this exposed.
llvm-svn: 102768
|
| |
|
|
|
|
| |
least on 64 bit platforms).
llvm-svn: 102712
|
| |
|
|
| |
llvm-svn: 102709
|
| |
|
|
| |
llvm-svn: 101689
|
| |
|
|
| |
llvm-svn: 99633
|
| |
|
|
|
|
|
| |
aligned storage, the capacity may be more than what is explicitly
requested.
llvm-svn: 98846
|
| |
|
|
| |
llvm-svn: 98701
|
| |
|
|
|
|
|
|
| |
payloads. APFloat's internal folding routines always make QNaNs now,
instead of sometimes making QNaNs and sometimes SNaNs depending on the
type.
llvm-svn: 97364
|
| |
|
|
| |
llvm-svn: 97278
|
| |
|
|
| |
llvm-svn: 95862
|
| |
|
|
| |
llvm-svn: 95779
|
| |
|
|
|
|
|
| |
restriction in BitVector for |= and ^= that the operand must be the
same length.
llvm-svn: 95768
|
| |
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 95700
|
| |
|
|
|
|
| |
as undefined. Fixes an assertion in APFloat::toString noticed by Dale.
llvm-svn: 95196
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 92730
|
| |
|
|
|
| |
warning: comparison between signed and unsigned integer expressions
llvm-svn: 92359
|
| |
|
|
|
|
| |
to SmallVector, and add a unit test.
llvm-svn: 92340
|
| |
|
|
|
|
| |
major bugs in long-precision conversion.
llvm-svn: 92150
|
| |
|
|
|
|
|
| |
will be found by argument-dependent lookup. As with the previous
commit, GCC is allowing ill-formed code.
llvm-svn: 92146
|
| |
|
|
|
|
|
|
| |
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).
llvm-svn: 92144
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 92126
|
| |
|
|
|
|
| |
bit more verbose, but optimize to much shorter code.
llvm-svn: 91817
|
| |
|
|
|
|
|
| |
- This is a pretty slow / memory intensive implementation, and I will likely
change it to an iterative model, but it works.
llvm-svn: 90447
|
| |
|
|
|
|
| |
fixes PR5395.
llvm-svn: 89385
|
| |
|
|
| |
llvm-svn: 89357
|
| |
|
|
|
|
|
| |
- I plan on fixing/workarounding this, but until then I'd like the bots to stay
green.
llvm-svn: 89077
|
| |
|
|
|
|
|
|
| |
one into
"a" + 0.
llvm-svn: 87084
|
| |
|
|
| |
llvm-svn: 87068
|
| |
|
|
| |
llvm-svn: 87058
|
| |
|
|
|
|
| |
Also, add unittests for find_first_of and find_first_not_of.
llvm-svn: 86770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 86636
|
| |
|
|
| |
llvm-svn: 85254
|
| |
|
|
|
|
| |
direct inclusion edge from System to Support.
llvm-svn: 85086
|