| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APInt uses Knuth's D algorithm for long division. In rare cases the
implementation applied a transformation that was not needed.
Added unit tests for long division. KnuthDiv() procedure is fully covered.
There is a case in APInt::divide() that I believe is never used (marked with
a comment) as all users of divide() handle trivial cases earlier.
Patch by Pawel Bylica!
http://reviews.llvm.org/D8448
llvm-svn: 233312
|
|
|
|
|
|
|
| |
To complement getSplat. This is more general than the binary
decomposition method as it also handles non-pow2 splat sizes.
llvm-svn: 233195
|
|
|
|
|
|
| |
a subsequent commit in Clang.
llvm-svn: 233159
|
|
|
|
|
|
|
|
| |
Enable removing .str() member calls for these frequent cases.
http://reviews.llvm.org/D6372
llvm-svn: 232465
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch consists of the suggestions of clang-tidy/misc-static-assert check.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: xazax.hun, llvm-commits
Differential Revision: http://reviews.llvm.org/D8343
llvm-svn: 232366
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CloudABI is a POSIX-like runtime environment built around the concept of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
CloudABI uses its own ELFOSABI number. This number has been allocated by
the maintainers of ELF a couple of days ago.
Reviewed by: echristo
llvm-svn: 231681
|
|
|
|
|
|
| |
All supported platforms have half-way decent C99 support.
llvm-svn: 231679
|
|
|
|
|
|
|
| |
In the presence of a user-declared dtor, calling an implicit copy ctor
is deprecated in C++11.
llvm-svn: 231256
|
|
|
|
|
|
|
| |
Using the implicit default copy assignment operator in the presence of a
user-declared copy ctor is deprecated in C++11.
llvm-svn: 231225
|
|
|
|
|
|
|
|
|
|
|
| |
implicit default"
Accidentally committed a few more of these cleanup changes than
intended. Still breaking these out & tidying them up.
This reverts commit r231135.
llvm-svn: 231136
|
|
|
|
|
|
|
|
|
|
| |
There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.
llvm-svn: 231135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class.
Without this, use of this copy ctor is deprecated in C++11 due to the
presence of a user-declared dtor.
Marking the class final is just a little extra security that there are
no further derived classes that may then end up using the intermediate
base class's copy assignment operator and cause slicing to occur.
I didn't bother marking the other (non-test) base class final, since it
has reference members so it won't have any implicit assignment operators
anyway. Open to ideas on that, though.
We probably want a warning about use of a slicing assignment operator,
then I wouldn't worry so much about marking the class as final.
llvm-svn: 231114
|
|
|
|
|
|
| |
are not deprecated.
llvm-svn: 231112
|
|
|
|
|
|
| |
disable/deprecate the implicit copy assignment operator
llvm-svn: 231108
|
|
|
|
|
|
| |
Modeled after std::vector.
llvm-svn: 231015
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With initializer lists there is a really neat idiomatic way to write
this, 'ArrayRef.equals({1, 2, 3, 4, 5})'. Remove the equal method which
always had a hard limit on the number of arguments. I considered
rewriting it with variadic templates but that's not really a good fit
for a function with homogeneous arguments.
'ArrayRef == {1, 2, 3, 4, 5}' would've been even more awesome, but C++11
doesn't allow init lists with binary operators.
llvm-svn: 230907
|
|
|
|
|
|
| |
initializer lists. Should also silence a -Wsign-compare warning accidentally introduced.
llvm-svn: 229515
|
|
|
|
|
|
| |
values and as function arguments also work as expected.
llvm-svn: 229513
|
|
|
|
|
|
| |
initialization.
llvm-svn: 229512
|
|
|
|
|
|
|
|
| |
MSVC 2013 and GCC. Added a trivial test to ensure the ArrayRef initializer list constructor is called and behaves as expected.
If any of the bots complain (perhaps due to an antiquated version of an STL implementation), I will revert.
llvm-svn: 229502
|
|
|
|
| |
llvm-svn: 229501
|
|
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
|
|
|
|
|
|
|
|
| |
I just realized that the specialized metadata node patch I'm about to
commit won't compile on old compilers. Bump `hash_combine()`'s support
for non-variadic templates to 18 (I tested this by reversing the logic
in the #ifdef).
llvm-svn: 228629
|
|
|
|
|
|
|
| |
This resolves the strange effect that emplace_back is only available
when the type contained in the vector is not trivially copyable.
llvm-svn: 228496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add some API to `APSInt` to make it easier to compare with `int64_t`.
- `APSInt::compareValues(APSInt, APSInt)` returns 1, -1 or 0 for
greater, lesser, or equal, doing the right thing for mismatched
"has-sign" and bitwidths. This is just like `isSameValue()` (and is
now the implementation of it).
- `APSInt::get(int64_t)` gets a signed `APSInt`.
- `operator<(int64_t)`, etc., are implemented trivially via `get()`
and `compareValues()`.
- Also added `APSInt::getUnsigned(uint64_t)` to make it easier to test
`compareValues()`.
llvm-svn: 228239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
suffix it seems:
# ./config.guess
earmv7hfeb-unknown-netbsd7.99.4
Extend the triple parsing to support this. Avoid running the ARM parser
multiple times because StringSwitch is not lazy.
Reviewers: Renato Golin, Tim Northover
Differential Revision: http://reviews.llvm.org/D7166
llvm-svn: 227085
|
|
|
|
|
|
|
|
| |
This makes it possible to move between SmallVectors of different sizes.
Thanks to Dave Blaikie and Duncan Smith for patch feedback.
llvm-svn: 226899
|
|
|
|
|
|
| |
complement the ArrayRef implicit conversion operator.
llvm-svn: 226428
|
|
|
|
|
|
| |
complain that the flag doesn't exist.
llvm-svn: 225931
|
|
|
|
| |
llvm-svn: 225788
|
|
|
|
| |
llvm-svn: 225754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.
Unit tests for this case and related signed zero FMA results are included.
Fixes <rdar://problem/18925551>.
llvm-svn: 225123
|
|
|
|
|
|
|
|
|
|
|
| |
ArrayRef<T*> where T is a base of U.
This appears to have broken at least the windows build bots due to
compile errors in the predicate that didn't simply supress the overload.
I'm not sure what the fix is, and the bots have been broken for a long
time now so I'm just reverting until Michael can figure out a fix.
llvm-svn: 225064
|
|
|
|
|
|
|
|
|
| |
the other that takes in an ArrayRef<EltTy>
Currently one can only construct an empty TinyPtrVector. These are just missing
elements of the API.
llvm-svn: 225055
|
|
|
|
|
|
| |
and a Vector of SmallVector.
llvm-svn: 225054
|
|
|
|
|
|
| |
where T is a base of U.
llvm-svn: 225053
|
|
|
|
| |
llvm-svn: 223238
|
|
|
|
| |
llvm-svn: 223201
|
|
|
|
|
|
|
|
|
| |
If the template specialization for externally managed sets in
PostOrderIterator call too far out of sync with each other, this unit
test will fail to build. This is especially useful for developers who
may not build Clang (the only in-tree user) every time.
llvm-svn: 222447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMultiplyAdd method can return
incorrect results for x87DoubleExtended (x86_fp80) values. This commonly
manifests as incorrect constant folding of libm fmal calls on x86. E.g.
fmal(1.0L, 1.0L, 3.0L) == 0.0L (should be 4.0L)
This patch fixes PR20728 by adding an extra bit to the significand for
intermediate results of APFloat::multiplySignificand, avoiding the overflow.
llvm-svn: 222374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
|
|
|
|
|
|
|
|
| |
StringMap operations.
Followup to r221946.
llvm-svn: 221958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A subtle bug was found where attempting to copy a non-const function_ref
lvalue would actually invoke the generic forwarding constructor (as it
was a closer match - being T& rather than the const T& of the implicit
copy constructor). In the particular case this lead to a dangling
function_ref member (since it had referenced the function_ref passed by
value to its ctor, rather than the outer function_ref that was still
alive)
SFINAE the converting constructor to not be considered if the copy
constructor is available and demonstrate that this causes the copy to
refer to the original functor, not to the function_ref it was copied
from. (without the code change, the test would fail as Y would be
referencing X and Y() would see the result of the mutation to X, ie: 2)
llvm-svn: 221753
|
|
|
|
|
|
|
|
|
|
| |
MapVector::begin(), MapVector::end().
These just delegate to the underlying vector type in the MapVector.
Also just add in some sanity unittests.
llvm-svn: 220687
|
|
|
|
|
|
|
|
|
|
| |
This operation is analogous to its counterpart in DenseMap: It allows lookup
via cheap-to-construct keys (provided that getHashValue and isEqual are
implemented for the cheap key-type in the DenseMapInfo specialization).
Thanks to Chandler for the review.
llvm-svn: 220168
|
|
|
|
|
|
| |
by value having cleared the sign bit.
llvm-svn: 219485
|
|
|
|
| |
llvm-svn: 219475
|
|
|
|
|
|
|
|
| |
to what we actually want ilogb implementation. This makes everything
*much* easier to deal with and is actually what we want when using it
anyways.
llvm-svn: 219474
|
|
|
|
| |
llvm-svn: 219473
|
|
|
|
|
|
| |
to implement complex division in the constant folder of Clang.
llvm-svn: 219471
|