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/PR26569.cpp

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

21 lines
1.6 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 -triple i686-pc-win32 -fms-extensions -emit-llvm -O1 -disable-llvm-passes %s -o - | FileCheck %s
Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables"" This reverts commit r260449. We would supress our emission of vftable definitions if we thought another translation unit would provide the definition because we saw an explicit instantiation declaration. This is not the case with dllimport, we want to synthesize a definition of the vftable regardless. This fixes PR26569. llvm-svn: 260548
2016-02-12 01:49:28 +08:00
Also don't inline dllimport functions referring to non-dllimport constructors. The AST walker wasn't visiting CXXConstructExprs before. This is a follow-up to r281395. llvm-svn: 281413
2016-09-14 06:51:42 +08:00
class __declspec(dllimport) A {
Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables"" This reverts commit r260449. We would supress our emission of vftable definitions if we thought another translation unit would provide the definition because we saw an explicit instantiation declaration. This is not the case with dllimport, we want to synthesize a definition of the vftable regardless. This fixes PR26569. llvm-svn: 260548
2016-02-12 01:49:28 +08:00
virtual void m_fn1();
};
template <typename>
[MS ABI] Correctly handle dllimport'd explicit instantiation declaration w/ vbases We gave a VBTable dllimport storage class and external linkage while also providing an initializer. An initializer is only valid if the VBTable has available_externally linkage. Fix this by setting the linkage to available_externally in situ while generating the initializer. This fixes PR26686. llvm-svn: 261535
2016-02-23 01:22:08 +08:00
class B : virtual A {};
Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables"" This reverts commit r260449. We would supress our emission of vftable definitions if we thought another translation unit would provide the definition because we saw an explicit instantiation declaration. This is not the case with dllimport, we want to synthesize a definition of the vftable regardless. This fixes PR26569. llvm-svn: 260548
2016-02-12 01:49:28 +08:00
extern template class __declspec(dllimport) B<int>;
class __declspec(dllexport) C : B<int> {};
[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-DAG: @[[VTABLE_C:.*]] = private unnamed_addr constant { [2 x i8*] } { [2 x i8*] [i8* bitcast (%rtti.CompleteObjectLocator* @"??_R4C@@6B@" to i8*), i8* bitcast (void (%class.A*)* @"?m_fn1@A@@EAEXXZ" to i8*)] }
// CHECK-DAG: @[[VTABLE_B:.*]] = private unnamed_addr constant { [2 x i8*] } { [2 x i8*] [i8* bitcast (%rtti.CompleteObjectLocator* @"??_R4?$B@H@@6B@" to i8*), i8* bitcast (void (%class.A*)* @"?m_fn1@A@@EAEXXZ" to i8*)] }, comdat($"??_S?$B@H@@6B@")
// CHECK-DAG: @[[VTABLE_A:.*]] = private unnamed_addr constant { [2 x i8*] } { [2 x i8*] [i8* bitcast (%rtti.CompleteObjectLocator* @"??_R4A@@6B@" to i8*), i8* bitcast (void (%class.A*)* @"?m_fn1@A@@EAEXXZ" to i8*)] }, comdat($"??_SA@@6B@")
[MS ABI] Correctly handle dllimport'd explicit instantiation declaration w/ vbases We gave a VBTable dllimport storage class and external linkage while also providing an initializer. An initializer is only valid if the VBTable has available_externally linkage. Fix this by setting the linkage to available_externally in situ while generating the initializer. This fixes PR26686. llvm-svn: 261535
2016-02-23 01:22:08 +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-DAG: @"??_7C@@6B@" = dllexport unnamed_addr alias i8*, getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @[[VTABLE_C]], i32 0, i32 0, i32 1)
// CHECK-DAG: @"??_S?$B@H@@6B@" = unnamed_addr alias i8*, getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @[[VTABLE_B]], i32 0, i32 0, i32 1)
// CHECK-DAG: @"??_SA@@6B@" = unnamed_addr alias i8*, getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @[[VTABLE_A]], i32 0, i32 0, i32 1)
[MS ABI] Correctly handle dllimport'd explicit instantiation declaration w/ vbases We gave a VBTable dllimport storage class and external linkage while also providing an initializer. An initializer is only valid if the VBTable has available_externally linkage. Fix this by setting the linkage to available_externally in situ while generating the initializer. This fixes PR26686. llvm-svn: 261535
2016-02-23 01:22:08 +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-DAG: @"??_8?$B@H@@7B@" = available_externally dllimport unnamed_addr constant [2 x i32] [i32 0, i32 4]