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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

46 lines
1.8 KiB
C++
Raw Normal View History

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC) This adds -no-opaque-pointers to clang tests whose output will change when opaque pointers are enabled by default. This is intended to be part of the migration approach described in https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9. The patch has been produced by replacing %clang_cc1 with %clang_cc1 -no-opaque-pointers for tests that fail with opaque pointers enabled. Worth noting that this doesn't cover all tests, there's a remaining ~40 tests not using %clang_cc1 that will need a followup change. Differential Revision: https://reviews.llvm.org/D123115
2022-04-07 18:03:55 +08:00
// RUN: %clang_cc1 -no-opaque-pointers -mconstructor-aliases %s -triple x86_64-windows-msvc -fms-extensions -emit-llvm -o - | FileCheck %s
[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
// 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() {}
};
[MS] Emit exported complete/vbase destructors Summary: Fixes PR44205 I checked, and deleting destructors are not affected. Reviewers: hans Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70931
2019-12-03 07:22:44 +08:00
// Virtually inherits from a non-dllimport base class. In this case, we can
// expect the DLL to provide a definition of the complete dtor. See
// dllexport-dtor-thunks.cpp.
[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()
[CodeGen] Apply 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments. * Adds 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments * Gates 'nonnull' on -f(no-)delete-null-pointer-checks * Introduces this-nonnull.cpp and microsoft-abi-this-nullable.cpp tests to explicitly test the behavior of this change * Refactors hundreds of over-constrained clang tests to permit these attributes, where needed * Updates Clang12 patch notes mentioning this change Reviewed-by: rsmith, jdoerfert Differential Revision: https://reviews.llvm.org/D17993
2020-11-17 07:04:55 +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"