maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/dllimport-dtor-thunks.cpp

46 lines
1.7 KiB
C++
Raw Normal View History

[MS] Don't bail on replacing dllimport vbase dtors with base dtors Fix PR32990 by effectively reverting r283063 and solving it a different way. We want to limit the hack to not replace equivalent available_externally dtors specifically to libc++, which uses always_inline. It seems certain versions of libc++ do not provide all the symbols that an explicit template instantiation is expected to provide. If we get to the code that forms a real alias, only *then* check if this is available_externally, and do that by asking a better question, which is "is this a declaration for the linker?", because *that's* what means we can't form an alias to it. As a follow-on simplification, remove the InEveryTU parameter. Its last use guarded this code for forming aliases, but we should never form aliases to declarations, regardless of what we know about every TU. llvm-svn: 315656
2017-10-13 08:53:02 +08:00
// RUN: %clang_cc1 -mconstructor-aliases %s -triple x86_64-windows-msvc -fms-extensions -emit-llvm -o - | FileCheck %s
// PR32990
// Introduces the virtual destructor. We should use the base destructor
// directly, no thunk needed.
struct __declspec(dllimport) ImportIntroVDtor {
virtual ~ImportIntroVDtor() {}
};
struct BaseClass {
virtual ~BaseClass() {}
};
// Non-virtually inherits from a non-dllimport base class. We should again call
// the derived base constructor directly. No need for the complete (aka vbase)
// destructor.
struct __declspec(dllimport) ImportOverrideVDtor : public BaseClass {
virtual ~ImportOverrideVDtor() {}
};
Revert "Fix for PR32990" This reverts commit r321239. It broke the Chromium DLL build: [8834/50217] LINK(DLL) icui18n.dll icui18n.dll.lib icui18n.dll.pdb FAILED: icui18n.dll icui18n.dll.lib icui18n.dll.pdb zrule.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl icu_60::UnicodeString::`vbase destructor'(void)" (__imp_??_DUnicodeString@icu_60@@QEAAXXZ) llvm-svn: 321298
2017-12-22 03:44:23 +08:00
// Virtually inherits from a non-dllimport base class. This time we need to call
// the complete destructor and emit it inline. It's not exported from the DLL,
// and it must be emitted.
[MS] Don't bail on replacing dllimport vbase dtors with base dtors Fix PR32990 by effectively reverting r283063 and solving it a different way. We want to limit the hack to not replace equivalent available_externally dtors specifically to libc++, which uses always_inline. It seems certain versions of libc++ do not provide all the symbols that an explicit template instantiation is expected to provide. If we get to the code that forms a real alias, only *then* check if this is available_externally, and do that by asking a better question, which is "is this a declaration for the linker?", because *that's* what means we can't form an alias to it. As a follow-on simplification, remove the InEveryTU parameter. Its last use guarded this code for forming aliases, but we should never form aliases to declarations, regardless of what we know about every TU. llvm-svn: 315656
2017-10-13 08:53:02 +08:00
struct __declspec(dllimport) ImportVBaseOverrideVDtor
: public virtual BaseClass {
virtual ~ImportVBaseOverrideVDtor() {}
};
extern "C" void testit() {
ImportIntroVDtor t1;
ImportOverrideVDtor t2;
ImportVBaseOverrideVDtor t3;
}
// The destructors are called in reverse order of construction. Only the third
// needs the complete destructor (_D).
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK-LABEL: define dso_local void @testit()
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
// CHECK: call void @"??_DImportVBaseOverrideVDtor@@QEAAXXZ"(%struct.ImportVBaseOverrideVDtor* %{{.*}})
// CHECK: call void @"??1ImportOverrideVDtor@@UEAA@XZ"(%struct.ImportOverrideVDtor* %{{.*}})
// CHECK: call void @"??1ImportIntroVDtor@@UEAA@XZ"(%struct.ImportIntroVDtor* %{{.*}})
[MS] Don't bail on replacing dllimport vbase dtors with base dtors Fix PR32990 by effectively reverting r283063 and solving it a different way. We want to limit the hack to not replace equivalent available_externally dtors specifically to libc++, which uses always_inline. It seems certain versions of libc++ do not provide all the symbols that an explicit template instantiation is expected to provide. If we get to the code that forms a real alias, only *then* check if this is available_externally, and do that by asking a better question, which is "is this a declaration for the linker?", because *that's* what means we can't form an alias to it. As a follow-on simplification, remove the InEveryTU parameter. Its last use guarded this code for forming aliases, but we should never form aliases to declarations, regardless of what we know about every TU. llvm-svn: 315656
2017-10-13 08:53:02 +08:00
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
// CHECK-LABEL: declare dllimport void @"??_DImportVBaseOverrideVDtor@@QEAAXXZ"
// CHECK-LABEL: declare dllimport void @"??1ImportOverrideVDtor@@UEAA@XZ"
// CHECK-LABEL: declare dllimport void @"??1ImportIntroVDtor@@UEAA@XZ"