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;
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
// 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 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