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-rtti.cpp

34 lines
1.2 KiB
C++
Raw Normal View History

__declspec is not a core Clang language extension. Instead, require -fms-extensions or -fborland to enable the language extension. Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets. llvm-svn: 238238
2015-05-27 03:44:52 +08:00
// RUN: %clang_cc1 -triple i686-windows-msvc -emit-llvm -std=c++1y -fms-extensions -O1 -disable-llvm-optzns -o - %s | FileCheck %s --check-prefix=MSVC
// RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -std=c++1y -fms-extensions -O1 -disable-llvm-optzns -o - %s | FileCheck %s --check-prefix=GNU
MS ABI: Get linkage of RTTI data correct The Itanium rules are not appropriate for the MS ABI. RTTI data is _never_ imported and thus is never available_externally. It is either internal (if the type's linkage is internal) or linkonce_odr. This also means that classes which inherit from dllimport'd bases force their translation unit to duplicate the entirety of the RTTI data of that base. Interestingly, the complete object locator can never be referenced by translation units which import the class. This fixes PR20106. llvm-svn: 212256
2014-07-03 13:51:27 +08:00
struct __declspec(dllimport) S {
CodeGen, Itanium: Properly dllimport RTTI data We would blindly assume that RTTI data should have the same linkage as the vtable because we didn't think the RTTI data was external. This oversight stemmed because we didn't take dllimport into account. This fixes PR21512. llvm-svn: 221511
2014-11-07 15:26:38 +08:00
virtual void f() {}
MS ABI: Get linkage of RTTI data correct The Itanium rules are not appropriate for the MS ABI. RTTI data is _never_ imported and thus is never available_externally. It is either internal (if the type's linkage is internal) or linkonce_odr. This also means that classes which inherit from dllimport'd bases force their translation unit to duplicate the entirety of the RTTI data of that base. Interestingly, the complete object locator can never be referenced by translation units which import the class. This fixes PR20106. llvm-svn: 212256
2014-07-03 13:51:27 +08:00
} s;
CodeGen: New vtable group representation: struct of vtable arrays. 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
2016-12-14 04:40:39 +08:00
// MSVC: [[VF_S:.*]] = private unnamed_addr constant { [2 x i8*] }
// MSVC-DAG: @"\01??_SS@@6B@" = unnamed_addr alias i8*, getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* [[VF_S]], i32 0, i32 0, i32 1)
CodeGen, Itanium: Properly dllimport RTTI data We would blindly assume that RTTI data should have the same linkage as the vtable because we didn't think the RTTI data was external. This oversight stemmed because we didn't take dllimport into account. This fixes PR21512. llvm-svn: 221511
2014-11-07 15:26:38 +08:00
// MSVC-DAG: @"\01??_R0?AUS@@@8" = linkonce_odr
// MSVC-DAG: @"\01??_R1A@?0A@EA@S@@8" = linkonce_odr
// MSVC-DAG: @"\01??_R2S@@8" = linkonce_odr
// MSVC-DAG: @"\01??_R3S@@8" = linkonce_odr
// GNU-DAG: @_ZTV1S = available_externally dllimport
// GNU-DAG: @_ZTI1S = external dllimport
MS ABI: Get linkage of RTTI data correct The Itanium rules are not appropriate for the MS ABI. RTTI data is _never_ imported and thus is never available_externally. It is either internal (if the type's linkage is internal) or linkonce_odr. This also means that classes which inherit from dllimport'd bases force their translation unit to duplicate the entirety of the RTTI data of that base. Interestingly, the complete object locator can never be referenced by translation units which import the class. This fixes PR20106. llvm-svn: 212256
2014-07-03 13:51:27 +08:00
struct U : S {
} u;
[ItaniumCXXABI] Don't import RTTI data for classes with key functions MinGW has some pretty strange behvaior around RTTI and dllimport/dllexport: - RTTI data is never imported - RTTI data is only exported if the class has no key function. llvm-svn: 244266
2015-08-07 04:56:55 +08:00
struct __declspec(dllimport) V {
virtual void f();
} v;
// GNU-DAG: @_ZTV1V = available_externally dllimport
// GNU-DAG: @_ZTS1V = linkonce_odr
// GNU-DAG: @_ZTI1V = linkonce_odr
[dllimport] A non-imported class with an imported key can't have a key Summary: The vtable takes its DLL storage class from the class, not the key function. When they disagree, the vtable won't be exported by the DLL that defines the key function. The easiest way to ensure that importers of the class emit their own vtable is to say that the class has no key function. Reviewers: hans, majnemer Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11913 llvm-svn: 244488
2015-08-11 03:39:01 +08:00
struct W {
__declspec(dllimport) virtual void f();
virtual void g();
} w;
// GNU-DAG: @_ZTV1W = linkonce_odr
// GNU-DAG: @_ZTS1W = linkonce_odr
// GNU-DAG: @_ZTI1W = linkonce_odr