| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This does not conceptually belongs here. Instead provide a shortcut
getModule() that provides access to the DataLayout.
Reviewers: chandlerc, echristo
Reviewed By: echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8027
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231147
|
| |
|
|
|
|
|
|
|
|
| |
I removed the copy ctor, thinking that'd be the end of it - these
iterators should be perfectly assignable even from disjoint ranges (as
any iterator would be) - exkcept that the member was const.
Unconstify it.
llvm-svn: 231146
|
| |
|
|
|
|
|
| |
No functional change here, only deletes unnecessary headers
and moves one function's body from the .h file to the .cpp.
llvm-svn: 231145
|
| |
|
|
|
|
|
| |
This way, the copy assignment operator can be used without hitting the
deprecated case in C++11.
llvm-svn: 231144
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Rule of Zero
The assertion was just checking a class invariant that's pretty easy to
verify by inspection (no mutating operations, and the two non-copy ctors
already ensure the state is maintained) so remove the explicit copy ctor
in favor of the default, thus allowing the use of the default copy
assignment operator without hitting the C++11 deprecation here.
llvm-svn: 231143
|
| |
|
|
|
|
|
|
|
| |
There's no reason to disallow assigning an iterator from one range to an
iterator that previously iterated over a disjoint range. This then
follows the Rule of Zero, allowing implicit copy construction to be used
without hitting the case that's deprecated in C++11.
llvm-svn: 231142
|
| |
|
|
|
|
|
|
| |
construction as it is deprecated in C++11 in the presence of explicit copy assignment.
See r231099 for similar issues & details in [Small]BitVector.
llvm-svn: 231141
|
| |
|
|
|
|
|
| |
http://reviews.llvm.org/D8028
rdar://20023136
llvm-svn: 231140
|
| |
|
|
| |
llvm-svn: 231139
|
| |
|
|
|
|
|
|
|
|
| |
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: 231138
|
| |
|
|
|
|
|
|
| |
It has been part of the common functions since 1.0
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 231137
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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: 231134
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
which is deprecated in C++11 (due to the presence of a user-declare dtor in the base class)
This type could be made copyable (= default a protected copy ctor in the
base class, and preferably make the derived class final to avoid risks
of providing a slicing copy operation to further derived classes) but it
seemed easier to avoid that complexity for a dump function that I assume
(by symmetry with ResourcePriorityQueue's dump, which was actively
buggy) not often used.
llvm-svn: 231133
|
| |
|
|
| |
llvm-svn: 231132
|
| |
|
|
|
|
|
| |
Nothing from this header file was even being referenced in
Process.h anyway, so it was a completely unnecessary include.
llvm-svn: 231131
|
| |
|
|
|
|
|
|
|
| |
Previously we had only Linux using DTPOFF for these; all X86 ELF
targets should. Fixes a side issue mentioned in PR21077.
Differential Revision: http://reviews.llvm.org/D8011
llvm-svn: 231130
|
| |
|
|
| |
llvm-svn: 231129
|
| |
|
|
|
|
|
|
| |
section gc.
Patch by Bill Rushmore.
llvm-svn: 231128
|
| |
|
|
| |
llvm-svn: 231127
|
| |
|
|
|
|
| |
type which would result in a double-delete
llvm-svn: 231126
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was landed in r231035 and reverted because it was buggy.
This is fixed version of the same change.
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Reviewers: dexonsmith, dberlin, ruiu, chandlerc
Reviewed By: chandlerc
Subscribers: yaron.keren, chandlerc, llvm-commits
Differential Revision: http://reviews.llvm.org/D7931
llvm-svn: 231125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With out this patch,
"clang -help" prints "USAGE: clang-3 [options] <inputs>".
It should either print
USAGE: clang [options] <inputs>
or
USAGE: clang-3.7 [options] <inputs>
With this patch, on Linux, it prints
USAGE: clang-3.7 [options] <inputs>
On Windows, it prints
USAGE: clang.exe [options] <inputs>
llvm-svn: 231124
|
| |
|
|
| |
llvm-svn: 231123
|
| |
|
|
| |
llvm-svn: 231122
|
| |
|
|
|
|
|
|
| |
frame register before checking if there is a DWARF register number for it.
Thanks to H.J. Lu for diagnosing this and providing the testcase!
llvm-svn: 231121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The inferior can load the library now, but the remote test is still failing
because of a module loading problem in LLDB.
Reviewers: ovyalov, sivachandra, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8038
llvm-svn: 231120
|
| |
|
|
|
|
| |
Patch from eugenis
llvm-svn: 231119
|
| |
|
|
|
|
|
|
|
|
|
|
| |
valid type for Altivec support for Power.
There are two test case updates for very basic testing. While I was editing cxx-altivec.cpp I also updated it to better match some other changes in altivec.c.
Note: "vector bool long" was not also added because its use is considered deprecated.
http://reviews.llvm.org/D7235
llvm-svn: 231118
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7865
llvm-svn: 231117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vaddudm
vsubudm
vmulesw
vmulosw
vmuleuw
vmulouw
vmuluwm
vmaxsd
vmaxud
vminsd
vminud
vcmpequd
vcmpequd.
vcmpgtsd
vcmpgtsd.
vcmpgtud
vcmpgtud.
vrld
vsld
vsrd
vsrad
Phabricator review: http://reviews.llvm.org/D7959
llvm-svn: 231115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
disable/deprecate the copy operations.
llvm-svn: 231113
|
| |
|
|
|
|
| |
are not deprecated.
llvm-svn: 231112
|
| |
|
|
|
|
| |
where it is so that future generations can understand.
llvm-svn: 231111
|
| |
|
|
|
|
| |
the copy assignment operator is not deprecated.
llvm-svn: 231110
|
| |
|
|
|
|
| |
avoid disabling/deprecating the implicit copy ctor.
llvm-svn: 231109
|
| |
|
|
|
|
| |
disable/deprecate the implicit copy assignment operator
llvm-svn: 231108
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
|
| |
|
|
|
|
|
|
|
| |
Use llvm.eh.begincatch for Microsoft-style catches.
This moves lots of CGException code into ItaniumCXXABI. Sorry for the
blame pain.
llvm-svn: 231105
|
| |
|
|
|
|
|
| |
Making this type a little harder to abuse (see workaround relating to
use of the implicit copy ctor in the prior commit)
llvm-svn: 231104
|
| |
|
|
| |
llvm-svn: 231103
|
| |
|
|
|
|
| |
their presence makes the use of the implicit copy ctor deprecated in C++11
llvm-svn: 231102
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Needed to transfer stdout.txt to host before reading.
Reviewers: ovyalov, clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D8023
llvm-svn: 231101
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cause of the issue is the interaction of two factors:
1) When generating a DW_TAG_imported_declaration DIE which imports another
imported declaration, the code in AsmPrinter/DwarfCompileUnit.cpp
asserts that the second imported declaration must already have a DIE.
2) There is a non-determinism in the order in which imported declarations
within the same scope are processed.
Because of the non-determinism (2), it is possible that an imported
declaration is processed before another one it depends on, breaking the
assumption in (1).
The source of the non-determinism is that the imported declaration
DIDescriptors are sorted by scope in DwarfDebug::beginModule(); however that
sort is not a stable_sort, therefore the order of the declarations within
the same scope is not preserved. The attached patch changes the std::sort to
a std::stable_sort and it fixes the problem.
Test omitted due to it being non-deterministic and depending on the
implementation of std::sort.
llvm-svn: 231100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deprecated in C++11 in the presence of explicit copy assignment.
I tried making these private & friended to the BitVector, but that
didn't work - there's one use of BitVector::reference in Clang that
actually copies it into a local variable & uses it from there, rather
than just using the result of op[] in a temporary expression.
Whether or not this is desired is debatable (we could just fix that one
use in Clang) & it's not clear which way the C++ standard falls on this
for std::bitset's reference type (it has the same bug at least in
libstdc++, but Clang's -Wdeprecated doesn't flag it, because it's in a
standard header)
While it was only BitVector::reference's copy ctor that was referenced
by user code, I made SmallBitVector::reference's copy ctor public too,
for consistency.
llvm-svn: 231099
|
| |
|
|
| |
llvm-svn: 231098
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is part of a larger effort to reduce header file footprints.
Combined, these patches reduce the build time of LLDB locally by
over 30%. However, they touch many files and make many changes,
so will be submitted in small incremental pieces.
Reviewed By: Greg Clayton
Differential Revision: http://reviews.llvm.org/D8022
llvm-svn: 231097
|
| |
|
|
|
|
| |
problems
llvm-svn: 231096
|