summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/microsoft-abi-vtables-single-inheritance.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MS] Don't escape MS C++ names with \01Reid Kleckner2018-03-161-9/+9
| | | | | | | It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
* CodeGen: New vtable group representation: struct of vtable arrays.Peter Collingbourne2016-12-131-5/+5
| | | | | | | | | In a future change, this representation will allow us to use the new inrange annotation on getelementptr to allow the optimizer to split vtable groups. Differential Revision: https://reviews.llvm.org/D22296 llvm-svn: 289584
* [MS ABI] Let arbitrary entities participate in vftable orderingDavid Majnemer2015-11-191-0/+15
| | | | | | | | | | | In the Microsoft ABI, the vftable is laid out in the order in the declaration order of the entities defined within it. Obviously, only virtual methods end up in the vftable but they will be placed into the table at the same position as the first entity with the same name. llvm-svn: 253523
* MS ABI: Move test from virtual-inheritance to single-inheritanceDavid Majnemer2014-10-031-0/+10
| | | | | | The test didn't actually use virtual inheritance. llvm-svn: 218966
* Simplify test/CodeGenCXX/microsoft-abi-vtables-single-inheritance.cpp by ↵Timur Iskhodzhanov2014-03-211-134/+136
| | | | | | | | forcing VFTableBuilder invocation with virtual function calls Previously the vftables were built at the end of the TU in a reverse-to-random order llvm-svn: 204455
* Style fix: replace "1 entries" with "1 entry" in the vftable layout dumping codeTimur Iskhodzhanov2014-03-051-2/+2
| | | | llvm-svn: 202978
* MS ABI: Fix vftable mangling by using the vbtable name algorithmReid Kleckner2014-02-271-3/+3
| | | | | | | | | | | | | | | | | | Summary: This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold almost the same information. With that change, the vbtable mangling code can easily be applied to vftable data and we magically get the correct, unambiguous vftable names. Fixes PR17748. Reviewers: timurrrr, majnemer CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2893 llvm-svn: 202425
* MS ABI: Let non-virtual method overloads participate in vftable orderingReid Kleckner2014-02-191-0/+27
| | | | | | | | | | | | | In the Microsoft ABI, the vftable is laid out as if all methods in every overload set were declared in reverse order of declaration at the point of declaration of the first overload in the set. Previously we only considered virtual methods in an overload set, but MSVC includes non-virtual methods for ordering purposes. Fixes PR18902. llvm-svn: 201722
* Remove the -cxx-abi command-line flag.Hans Wennborg2014-01-141-1/+1
| | | | | | | | | | | | | | | This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples, Itanium otherwise. It's no longer possible to do weird combinations. To be able to run a test with a specific ABI without constraining it to a specific triple, new substitutions are added to lit: %itanium_abi_triple and %ms_abi_triple can be used to get the current target triple adjusted to the desired ABI. For example, if the test suite is running with the i686-pc-win32 target, %itanium_abi_triple will expand to i686-pc-mingw32. Differential Revision: http://llvm-reviews.chandlerc.com/D2545 llvm-svn: 199250
* [ms-cxxabi] Emit fewer trivial return adjusting thunksReid Kleckner2013-12-271-5/+4
| | | | | | | | | | | Most importantly, this makes our vtable layout match MSVC's. Previously we would emit a return adjusting thunk whenever the return types differed, even if the adjustment would have been trivial. MSVC does emit some trivial return adjusting thunks, but only if there was already an overridden method that required a return adjustment. llvm-svn: 198080
* Compare canonical return types when generating MS C++ ABI vtable thunksReid Kleckner2013-12-201-0/+11
| | | | | | | | This was part of the cause for PR17655. We were generating thunks when we shouldn't have. I suspect that if we tweak the test case for PR17655 to actually require thunks, we can reproduce the same crash. llvm-svn: 197836
* Make -fdump-vtable-layouts print to stdout, not stderrReid Kleckner2013-11-081-3/+3
| | | | | | | | | | | | | This makes it consistent with -fdump-record-layouts, which was moved to outs() in r186219. My reasoning for going with stdout is that when one of these options is present, the layouts are really a program output, and shouldn't be interleaved with diagnostics, which are on stderr. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D2127 llvm-svn: 194279
* Fix PR17382 - properly group virtual method overloads in the vftableTimur Iskhodzhanov2013-10-061-0/+101
| | | | llvm-svn: 192067
* Abstract out the emission of vtables, add basic support for vtable emission ↵Timur Iskhodzhanov2013-09-271-65/+15
| | | | | | | | when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1532 llvm-svn: 191523
* Abstract out virtual calls and virtual function prologue code generation; ↵Timur Iskhodzhanov2013-08-211-2/+2
| | | | | | implement them for -cxx-abi microsoft llvm-svn: 188870
* Add MicrosoftVFTableContext to ASTTimur Iskhodzhanov2013-07-301-2/+80
| | | | llvm-svn: 187409
* [ms-cxxabi] Fix r182865 to have an actual Itanium-style key functionReid Kleckner2013-05-291-1/+7
| | | | | | | Peter pointed out that C::f() is not a key function. C's key function is actually C::~C(). llvm-svn: 182866
* [ms-cxxabi] There are no key functions in the Microsoft C++ ABIReid Kleckner2013-05-291-11/+15
| | | | | | | | | | | MSVC's class data is always comdat, so clang's should always be linkonce_odr in LLVM IR. Reviewers: pcc Differential Revision: http://llvm-reviews.chandlerc.com/D838 llvm-svn: 182865
* Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058Timur Iskhodzhanov2013-02-131-9/+9
| | | | llvm-svn: 175045
* First step towards vftable generation with -cxx-abi microsoft PR13231Timur Iskhodzhanov2013-01-211-0/+113
llvm-svn: 173035
OpenPOWER on IntegriCloud