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

50 lines
1.9 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
// FIXME: We should really consider removing -mconstructor-aliases for MS C++
// ABI. The risk of bugs introducing ABI incompatibility under
// -mno-constructor-aliases is too high.
// 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).
Revert "Start setting dso_local for COFF." This reverts commit r325915. It will take some time to fix the failures on a windows host. llvm-svn: 325929
2018-02-24 02:09:29 +08:00
// CHECK-LABEL: define void @testit()
[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
// CHECK: call void @"\01??_DImportVBaseOverrideVDtor@@QEAAXXZ"(%struct.ImportVBaseOverrideVDtor* %{{.*}})
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
// CHECK: call void @"\01??1ImportOverrideVDtor@@UEAA@XZ"(%struct.ImportOverrideVDtor* %{{.*}})
// CHECK: call void @"\01??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
Revert "Start setting dso_local for COFF." This reverts commit r325915. It will take some time to fix the failures on a windows host. llvm-svn: 325929
2018-02-24 02:09:29 +08:00
// CHECK-LABEL: define linkonce_odr void @"\01??_DImportVBaseOverrideVDtor@@QEAAXXZ"
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
// CHECK-LABEL: declare dllimport void @"\01??1ImportOverrideVDtor@@UEAA@XZ"
// CHECK-LABEL: declare dllimport void @"\01??1ImportIntroVDtor@@UEAA@XZ"