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/microsoft-abi-static-initia...

170 lines
4.5 KiB
C++
Raw Normal View History

MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// RUN: %clang_cc1 -fms-extensions -emit-llvm %s -o - -mconstructor-aliases -triple=i386-pc-win32 | FileCheck %s
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: @llvm.global_ctors = appending global [2 x { i32, void ()*, i8* }]
// CHECK: [{ i32, void ()*, i8* } { i32 65535, void ()* @"\01??__Efoo@?$B@H@@2VA@@A@YAXXZ",
// CHECK: i8* bitcast (%class.A* @"\01?foo@?$B@H@@2VA@@A" to i8*) },
// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I_microsoft_abi_static_initializers.cpp, i8* null }]
Add a separate llvm.global_ctors entry for linkonce_odr data initializers Summary: These typically come from static data members of class template specializations. This accomplishes two things: 1. May expose GlobalOpt optimizations for Itanium C++ ABI code. 2. Works toward fixing double initialization in the Microsoft C++ ABI. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1475 llvm-svn: 189051
2013-08-23 04:07:45 +08:00
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
struct S {
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
S();
~S();
};
S s;
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define internal void @"\01??__Es@@YAXXZ"()
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: call i32 @atexit(void ()* @"\01??__Fs@@YAXXZ")
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define internal void @"\01??__Fs@@YAXXZ"()
[Windows] Use thiscall as the default calling convention for class methods. PR12785 llvm-svn: 160121
2012-07-12 17:50:54 +08:00
// CHECK: call x86_thiscallcc void @"\01??1S@@QAE@XZ"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// These globals should use distinct guard variables, and not different bits of
// the same global.
__declspec(selectany) S selectany1;
__declspec(selectany) S selectany2;
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Eselectany1@@YAXXZ"()
// CHECK-NOT: @"\01??_Bselectany1
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"
MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// CHECK: ret void
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Eselectany2@@YAXXZ"()
// CHECK-NOT: @"\01??_Bselectany2
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"
MS ABI: Use a different guard variable for each weak global We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
2014-04-24 02:22:11 +08:00
// CHECK: ret void
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
void StaticLocal() {
static S TheS;
}
// CHECK-LABEL: define void @"\01?StaticLocal@@YAXXZ"()
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// CHECK: load i32* @"\01?$S1@?0??StaticLocal@@YAXXZ@4IA"
// CHECK: store i32 {{.*}}, i32* @"\01?$S1@?0??StaticLocal@@YAXXZ@4IA"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: ret
void MultipleStatics() {
static S S1;
static S S2;
static S S3;
static S S4;
static S S5;
static S S6;
static S S7;
static S S8;
static S S9;
static S S10;
static S S11;
static S S12;
static S S13;
static S S14;
static S S15;
static S S16;
static S S17;
static S S18;
static S S19;
static S S20;
static S S21;
static S S22;
static S S23;
static S S24;
static S S25;
static S S26;
static S S27;
static S S28;
static S S29;
static S S30;
static S S31;
static S S32;
static S S33;
static S S34;
static S S35;
}
// CHECK-LABEL: define void @"\01?MultipleStatics@@YAXXZ"()
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// CHECK: load i32* @"\01?$S1@?0??MultipleStatics@@YAXXZ@4IA"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: and i32 {{.*}}, 1
// CHECK: and i32 {{.*}}, 2
// CHECK: and i32 {{.*}}, 4
// CHECK: and i32 {{.*}}, 8
// CHECK: and i32 {{.*}}, 16
// ...
// CHECK: and i32 {{.*}}, -2147483648
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
// CHECK: load i32* @"\01?$S1@?0??MultipleStatics@@YAXXZ@4IA1"
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK: and i32 {{.*}}, 1
// CHECK: and i32 {{.*}}, 2
// CHECK: and i32 {{.*}}, 4
// CHECK: ret
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// Force WeakODRLinkage by using templates
class A {
public:
A() {}
~A() {}
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
int a;
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
};
template<typename T>
class B {
public:
static A foo;
};
template<typename T> A B<T>::foo;
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
inline S &UnreachableStatic() {
if (0) {
static S s; // bit 1
return s;
}
static S s; // bit 2
return s;
}
// CHECK-LABEL: define linkonce_odr %struct.S* @"\01?UnreachableStatic@@YAAAUS@@XZ"()
// CHECK: and i32 {{.*}}, 2
// CHECK: or i32 {{.*}}, 2
// CHECK: ret
inline S &getS() {
static S TheS;
return TheS;
}
// CHECK-LABEL: define linkonce_odr %struct.S* @"\01?getS@@YAAAUS@@XZ"
// CHECK: load i32* @"\01??_B?1??getS@@YAAAUS@@XZ@51"
// CHECK: and i32 {{.*}}, 1
// CHECK: icmp ne i32 {{.*}}, 0
// CHECK: br i1
// init:
// CHECK: or i32 {{.*}}, 1
// CHECK: store i32 {{.*}}, i32* @"\01??_B?1??getS@@YAAAUS@@XZ@51"
// CHECK: call x86_thiscallcc %struct.S* @"\01??0S@@QAE@XZ"(%struct.S* @"\01?TheS@?1??getS@@YAAAUS@@XZ@4U2@A")
// CHECK: call i32 @atexit(void ()* @"\01??__FTheS@?1??getS@@YAAAUS@@XZ@YAXXZ")
// CHECK: br label
// init.end:
// CHECK: ret %struct.S* @"\01?TheS@?1??getS@@YAAAUS@@XZ@4U2@A"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
void force_usage() {
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
UnreachableStatic();
getS();
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
(void)B<int>::foo; // (void) - force usage
}
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define linkonce_odr void @"\01??__Efoo@?$B@H@@2VA@@A@YAXXZ"()
// CHECK-NOT: and
// CHECK-NOT: ?_Bfoo@
// CHECK: call x86_thiscallcc %class.A* @"\01??0A@@QAE@XZ"
MS ABI: Fix the initializer/finalizer mangling for static data members Initializers and finalizers for static data members have the variable's access-specifier, storage-class, type and CV-qualifiers mangled in. llvm-svn: 203145
2014-03-07 03:10:27 +08:00
// CHECK: call i32 @atexit(void ()* @"\01??__Ffoo@?$B@H@@2VA@@A@YAXXZ")
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
In the MS ABI, ctors return 'this'. Patch by Dmitry Sokolov. llvm-svn: 164592
2012-09-25 16:00:39 +08:00
// CHECK: define linkonce_odr x86_thiscallcc %class.A* @"\01??0A@@QAE@XZ"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
[Windows] Use thiscall as the default calling convention for class methods. PR12785 llvm-svn: 160121
2012-07-12 17:50:54 +08:00
// CHECK: define linkonce_odr x86_thiscallcc void @"\01??1A@@QAE@XZ"
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
MS ABI: Fix the initializer/finalizer mangling for static data members Initializers and finalizers for static data members have the variable's access-specifier, storage-class, type and CV-qualifiers mangled in. llvm-svn: 203145
2014-03-07 03:10:27 +08:00
// CHECK: define internal void @"\01??__Ffoo@?$B@H@@2VA@@A@YAXXZ"
[Windows] Use thiscall as the default calling convention for class methods. PR12785 llvm-svn: 160121
2012-07-12 17:50:54 +08:00
// CHECK: call x86_thiscallcc void @"\01??1A@@QAE@XZ"{{.*}}foo
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// CHECK: define internal void @_GLOBAL__sub_I_microsoft_abi_static_initializers.cpp()
[ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC does Summary: Dynamic initializers are mangled as ??__E <name> YAXXZ. Reviewers: timurrrr CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1477 llvm-svn: 190434
2013-09-11 04:43:12 +08:00
// CHECK: call void @"\01??__Es@@YAXXZ"()
Abstract the emission of global destructors into ABI-specific code and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
2012-05-01 14:13:13 +08:00
// CHECK: ret void