| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
This was a bug in r218285 that prevented us from seeing subsequent
virtual bases in the class hierarchy, leading to crashes later.
Also add some comments to this function, now that we better understand
what it's trying to do.
Fixes PR21062 and PR21064.
llvm-svn: 235899
|
|
|
|
|
|
| |
Also merge anonymous namespaces in Targets.cpp a bit. NFC.
llvm-svn: 232945
|
|
|
|
|
|
|
|
|
| |
There will be an explicit template instantiation in another translation
unit which will provide the definition of the VF/VB-Tables.
This fixes PR22932.
llvm-svn: 232680
|
|
|
|
|
|
|
|
| |
exported from multiple modules."
This reverts commits r230477 and r230478.
llvm-svn: 230526
|
|
|
|
| |
llvm-svn: 230478
|
|
|
|
|
|
| |
(re-) exported from multiple modules."", since I have reverted r230446.
llvm-svn: 230477
|
|
|
|
|
|
|
|
|
|
| |
multiple modules."
This reverts the revert from commit r230406.
The changes in r230445 and r230446 make the test pass on Windows now.
llvm-svn: 230448
|
|
|
|
| |
llvm-svn: 230445
|
|
|
|
|
|
|
|
|
|
| |
from multiple modules."
It crashes for targeting (i686|x86_64)-win32.
clang: clang/lib/AST/VTableBuilder.cpp:142: {anonymous}::FinalOverriders::OverriderInfo {anonymous}::FinalOverriders::getOverrider(const clang::CXXMethodDecl*, clang::CharUnits) const: Assertion `OverridersMap.count(std::make_pair(MD, BaseOffset)) && "Did not find overrider!"' failed.
llvm-svn: 230406
|
|
|
|
|
|
|
| |
Fixes multiple crashes where a non-canonical decl would be used as key
in a lookup.
llvm-svn: 230314
|
|
|
|
| |
llvm-svn: 222964
|
|
|
|
|
|
| |
pair<iterator, bool> as per the C++ standard's associative container concept.
llvm-svn: 222335
|
|
|
|
| |
llvm-svn: 222140
|
|
|
|
| |
llvm-svn: 222133
|
|
|
|
| |
llvm-svn: 221997
|
|
|
|
|
|
| |
VFTableBuilder code
llvm-svn: 221996
|
|
|
|
| |
llvm-svn: 219504
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 218506
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to walk the class hierarchy twice: once in depth-first base
specifier order for mangling and again in depth-first layout order for
vftable layout.
Vftable layout seems to depend on the full path from the most derived
class to the base containing the vfptr.
Fixes PR21031.
llvm-svn: 218285
|
|
|
|
|
|
| |
We've implemented MSVC-style RTTI for quite some time.
llvm-svn: 218269
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deleted virtual functions get _purecall inserted into the vftable.
Earlier CTPs would simply stick nullptr in there.
N.B. MSVC can't handle deleted virtual functions which require return
adjusting thunks, they give an error that a deleted function couldn't be
called inside of a compiler generated function. We get this correct by
making the thunk have a __purecall entry as well.
llvm-svn: 217654
|
|
|
|
| |
llvm-svn: 216527
|
|
|
|
|
|
|
|
| |
thunks are needed
Reviewed at http://reviews.llvm.org/D4822
llvm-svn: 215312
|
|
|
|
|
|
|
|
| |
return adjusting thunks
Reviewed at http://reviews.llvm.org/D4829
llvm-svn: 215285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are slight differences between /GR- and -fno-rtti which made
mapping one to the other inappropriate.
-fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
information for the v-table.
/GR- does not generate complete object locators and thus will not
reference them in vftables. However, constructs like dynamic_cast and
typeid are permitted.
This should bring our implementation of RTTI up to semantic parity with
MSVC modulo bugs.
llvm-svn: 212138
|
|
|
|
|
|
|
| |
Stash whether or not we have an RTTI component away instead of
recomputing it.
llvm-svn: 212127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pointer for a class's RTTI data comes right before the VFTable but
has no name. To be properly compatible with this, we do the following:
* Create a single GlobalVariable which holds the contents of the VFTable
_and_ the pointer to the RTTI data.
* Create a GlobalAlias, with appropriate linkage/visibility, that points
just after the RTTI data pointer. This ensures that the VFTable
symbol will always refer to VFTable data.
* Create a Comdat with a "Largest" SelectionKind and stick the private
GlobalVariable in it. By transitivity, the GlobalAlias will be a
member of the Comdat group. Using "Largest" ensures that foreign
definitions without an RTTI data pointer will _not_ be chosen in the
final linked image.
Whether or not we emit RTTI data depends on several things:
* The -fno-rtti flag implies that we should never not emit a pointer to
RTTI data before the VFTable.
* __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
available_externally GlobalVariable to provide a local definition of
the VFTable. This means that we won't have any available_externally
definitions of things like complete object locators. This is
acceptable because they are never directly referenced.
To my knowledge, this completes the implementation of MSVC RTTI code
generation.
Further semantic work should be done to properly support /GR-.
llvm-svn: 212125
|
|
|
|
| |
llvm-svn: 211987
|
|
|
|
| |
llvm-svn: 208517
|
|
|
|
| |
llvm-svn: 207138
|
|
|
|
|
|
|
|
| |
overrider is present in both a vbase and nvbase
Reviewed at http://reviews.llvm.org/D3449
llvm-svn: 206908
|
|
|
|
|
|
|
| |
This was probably a benign bug, since nobody would look at the vbtable
slots that we were filling in.
llvm-svn: 206508
|
|
|
|
|
|
|
|
| |
inheritance cases
Reviewed at http://reviews.llvm.org/D3410
llvm-svn: 206504
|
|
|
|
|
|
|
|
| |
Also fix a few other vtordisp-related bugs.
Reviewed at http://reviews.llvm.org/D3400
llvm-svn: 206457
|
|
|
|
|
|
| |
MicrosoftVTableContext::computeVTablePaths(). No functionality changes.
llvm-svn: 205178
|
|
|
|
| |
llvm-svn: 204787
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3181
llvm-svn: 204786
|
|
|
|
|
|
| |
Fixes PR19240. In retrospect, this is a fairly obvious bug. :)
llvm-svn: 204744
|
|
|
|
|
|
|
|
| |
class with complex inheritance
Reviewed at http://llvm-reviews.chandlerc.com/D3128
llvm-svn: 204394
|
|
|
|
| |
llvm-svn: 204341
|
|
|
|
|
|
| |
with iterator_range methods(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203812
|
|
|
|
|
|
| |
with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203808
|
|
|
|
|
|
| |
iterator_range bases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203803
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203289
|
|
|
|
|
|
| |
inheritance hierarchy
llvm-svn: 203222
|
|
|
|
| |
llvm-svn: 202978
|
|
|
|
| |
llvm-svn: 202870
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202755
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202590
|