replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/clang/test/CodeGenCXX/static-init.cpp

174 lines
5.0 KiB
C++
Raw Normal View History

In the Itanium ABI, move stuff to the comdat of variables with static init. Clang can already handle ------------------------------------------- struct S { static const int x; }; template<typename T> struct U { static const int k; }; template<typename T> const int U<T>::k = T::x; const int S::x = 42; extern const int *f(); const int *g() { return &U<S>::k; } int main() { return *f() + U<S>::k; } const int *f() { return &U<S>::k; } ------------------------------------------- since r217264 which puts the .inint_array section in the same COMDAT as the variable. This patch allows the linker to more easily delete some dead code and data by putting the guard variable and init function in the same COMDAT. This is a fixed version of r218089. llvm-svn: 218141
2014-09-20 03:43:18 +08:00
// RUN: %clang_cc1 %s -triple=x86_64-pc-linuxs -emit-llvm -o - | FileCheck %s
Make sure to always mark a global variable as not being constant if it has a C++ initializer. llvm-svn: 94504
2010-01-26 12:02:23 +08:00
// CHECK: @_ZZ1hvE1i = internal global i32 0, align 4
Make sure constant emission handles initializer lists with strings correctly. Part of <rdar://problem/10957867>. llvm-svn: 152370
2012-03-09 11:06:56 +08:00
// CHECK: @base_req = global [4 x i8] c"foo\00", align 1
PR12226: don't generate wrong code if a braced string literal is used to initialize an array of unsigned char. Outside C++11 mode, this bug was benign, and just resulted in us emitting a constant which was double the required length, padded with 0s. In C++11, it resulted in us generating an array whose first element was something like i8 ptrtoint ([n x i8]* @str to i8). llvm-svn: 154756
2012-04-15 10:50:59 +08:00
// CHECK: @base_req_uchar = global [4 x i8] c"bar\00", align 1
Use the right linkage for static variables inside C++ inline functions. llvm-svn: 95512
2010-02-07 10:03:08 +08:00
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
// CHECK: @_ZZN5test31BC1EvE1u = internal global { i8, [3 x i8] } { i8 97, [3 x i8] undef }, align 4
In the Itanium ABI, move stuff to the comdat of variables with static init. Clang can already handle ------------------------------------------- struct S { static const int x; }; template<typename T> struct U { static const int k; }; template<typename T> const int U<T>::k = T::x; const int S::x = 42; extern const int *f(); const int *g() { return &U<S>::k; } int main() { return *f() + U<S>::k; } const int *f() { return &U<S>::k; } ------------------------------------------- since r217264 which puts the .inint_array section in the same COMDAT as the variable. This patch allows the linker to more easily delete some dead code and data by putting the guard variable and init function in the same COMDAT. This is a fixed version of r218089. llvm-svn: 218141
2014-09-20 03:43:18 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: @_ZZ2h2vE1i = linkonce_odr global i32 0, comdat, align 4
// CHECK: @_ZGVZ2h2vE1i = linkonce_odr global i64 0, comdat, align 8{{$}}
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// CHECK: @_ZZN5test1L6getvarEiE3var = internal constant [4 x i32] [i32 1, i32 0, i32 2, i32 4], align 16
Fix a case where we forgot to make a static local variable comdat Sometimes we can provide an initializer for static locals, in which case we sometimes might need to change the type. Changing the type requires making a new LLVM GlobalVariable, and in this codepath we were forgetting to transfer the comdat. Fixes PR23838. Patch by Ivan Garramona. llvm-svn: 242704
2015-07-21 04:35:30 +08:00
// CHECK: @_ZZN5test414useStaticLocalEvE3obj = linkonce_odr global %"struct.test4::HasVTable" zeroinitializer, comdat, align 8
Use the right linkage for static variables inside C++ inline functions. llvm-svn: 95512
2010-02-07 10:03:08 +08:00
Refactor some code and implement support for global destructors for static variables. llvm-svn: 78507
2009-08-09 05:45:14 +08:00
struct A {
A();
~A();
};
void f() {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// CHECK: load atomic i8, i8* bitcast (i64* @_ZGVZ1fvE1a to i8*) acquire, align 8
For thread-safe static initialization of local statics with destructors, place the __cxa_atexit call after the __cxa_guard_release call, mimicking GCC/LLVM-GCC behavior. Noticed while debugging something related. llvm-svn: 103088
2010-05-05 23:38:32 +08:00
// CHECK: call i32 @__cxa_guard_acquire
// CHECK: call void @_ZN1AC1Ev
Test case updates for explicit type parameter to the gep operator llvm-svn: 232187
2015-03-14 02:21:46 +08:00
// CHECK: call i32 @__cxa_atexit(void (i8*)* bitcast (void (%struct.A*)* @_ZN1AD1Ev to void (i8*)*), i8* getelementptr inbounds (%struct.A, %struct.A* @_ZZ1fvE1a, i32 0, i32 0), i8* @__dso_handle)
Implement ARM static local initialization guards, which are more compact than Itanium guards and use a slightly different compiled-in API. llvm-svn: 113330
2010-09-08 09:44:27 +08:00
// CHECK: call void @__cxa_guard_release
Refactor some code and implement support for global destructors for static variables. llvm-svn: 78507
2009-08-09 05:45:14 +08:00
static A a;
}
Handle emitting static variables that have reference type. llvm-svn: 91027
2009-12-10 09:05:11 +08:00
void g() {
Replace Sema-level implementation of -fassume-sane-operator-new with a CodeGen-level implementation. Instead of adding an attribute to clang's FunctionDecl, add the IR attribute directly. This means a module built with this flag is now compatible with code built without it and vice versa. This change also results in the 'noalias' attribute no longer being added to calls to operator new in the IR; it's now only added to the declaration. It also fixes a bug where we failed to add the attribute to the 'nothrow' versions (because we didn't implicitly declare them, there was no good time to inject a fake attribute). llvm-svn: 265728
2016-04-08 05:46:12 +08:00
// CHECK: call i8* @_Znwm(i64 1)
Handle emitting static variables that have reference type. llvm-svn: 91027
2009-12-10 09:05:11 +08:00
// CHECK: call void @_ZN1AC1Ev(
static A& a = *new A;
}
Make sure to always mark a global variable as not being constant if it has a C++ initializer. llvm-svn: 94504
2010-01-26 12:02:23 +08:00
int a();
void h() {
static const int i = a();
}
Use the right linkage for static variables inside C++ inline functions. llvm-svn: 95512
2010-02-07 10:03:08 +08:00
[patch][pr19848] Produce explicit comdats in clang. The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
2015-01-13 06:13:53 +08:00
// CHECK: define linkonce_odr void @_Z2h2v() {{.*}} comdat {
Use the right linkage for static variables inside C++ inline functions. llvm-svn: 95512
2010-02-07 10:03:08 +08:00
inline void h2() {
static int i = a();
}
void h3() {
h2();
}
Just bail out immediately when emitting an unreachable function-local static variable. Surprisingly, this does seem to be the right way to solve this. llvm-svn: 102961
2010-05-04 05:39:56 +08:00
// PR6980: this shouldn't crash
namespace test0 {
struct A { A(); };
__attribute__((noreturn)) int throw_exception();
void test() {
throw_exception();
static A r;
}
}
If a function definition has any sort of weak linkage, its static local variables should have that linkage. Otherwise, its static local variables should have internal linkage. To avoid computing this excessively, set a function's linkage before we emit code for it. Previously we were assigning weak linkage to the static variables of static inline functions in C++, with predictably terrible results. This fixes that and also gives better linkage than 'weak' when merging is required. llvm-svn: 104581
2010-05-25 12:30:21 +08:00
namespace test1 {
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define internal i32 @_ZN5test1L6getvarEi(
If a function definition has any sort of weak linkage, its static local variables should have that linkage. Otherwise, its static local variables should have internal linkage. To avoid computing this excessively, set a function's linkage before we emit code for it. Previously we were assigning weak linkage to the static variables of static inline functions in C++, with predictably terrible results. This fixes that and also gives better linkage than 'weak' when merging is required. llvm-svn: 104581
2010-05-25 12:30:21 +08:00
static inline int getvar(int index) {
static const int var[] = { 1, 0, 2, 4 };
return var[index];
}
void test() { (void) getvar(2); }
}
Make sure constant emission handles initializer lists with strings correctly. Part of <rdar://problem/10957867>. llvm-svn: 152370
2012-03-09 11:06:56 +08:00
// Make sure we emit the initializer correctly for the following:
char base_req[] = { "foo" };
PR12226: don't generate wrong code if a braced string literal is used to initialize an array of unsigned char. Outside C++11 mode, this bug was benign, and just resulted in us emitting a constant which was double the required length, padded with 0s. In C++11, it resulted in us generating an array whose first element was something like i8 ptrtoint ([n x i8]* @str to i8). llvm-svn: 154756
2012-04-15 10:50:59 +08:00
unsigned char base_req_uchar[] = { "bar" };
Make sure we update the static local decl address map when we are forced to rebuild a global because of the initializer. <rdar://problem/10957867>. llvm-svn: 152372
2012-03-09 11:27:46 +08:00
namespace union_static_local {
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define internal void @_ZZN18union_static_local4testEvEN1c4mainEv
Make sure we update the static local decl address map when we are forced to rebuild a global because of the initializer. <rdar://problem/10957867>. llvm-svn: 152372
2012-03-09 11:27:46 +08:00
// CHECK: call void @_ZN18union_static_local1fEPNS_1xE(%"union.union_static_local::x"* bitcast ({ [2 x i8*] }* @_ZZN18union_static_local4testEvE3foo to %"union.union_static_local::x"*))
union x { long double y; const char *x[2]; };
void f(union x*);
void test() {
static union x foo = { .x = { "a", "b" } };
struct c {
static void main() {
f(&foo);
}
};
c::main();
}
}
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
// rdar://problem/11091093
// Static variables should be consistent across constructor
// or destructor variants.
namespace test2 {
struct A {
A();
~A();
};
struct B : virtual A {
B();
~B();
};
// If we ever implement this as a delegate ctor call, just change
// this to take variadic arguments or something.
extern int foo();
B::B() {
static int x = foo();
}
Output destructors and constructors in a more natural order. With this patch we output the in the order C2 C1 D2 D1 D0 Which means that a destructor or constructor that call another is output after the callee. This is a bit easier to read IHMO and a tiny bit more efficient as we don't put a decl in DeferredDeclsToEmit. llvm-svn: 196784
2013-12-09 22:51:17 +08:00
// CHECK-LABEL: define void @_ZN5test21BC2Ev
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load atomic i8, i8* bitcast (i64* @_ZGVZN5test21BC1EvE1x to i8*) acquire,
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
// CHECK: call i32 @__cxa_guard_acquire(i64* @_ZGVZN5test21BC1EvE1x)
// CHECK: [[T0:%.*]] = call i32 @_ZN5test23fooEv()
// CHECK: store i32 [[T0]], i32* @_ZZN5test21BC1EvE1x,
// CHECK: call void @__cxa_guard_release(i64* @_ZGVZN5test21BC1EvE1x)
Output destructors and constructors in a more natural order. With this patch we output the in the order C2 C1 D2 D1 D0 Which means that a destructor or constructor that call another is output after the callee. This is a bit easier to read IHMO and a tiny bit more efficient as we don't put a decl in DeferredDeclsToEmit. llvm-svn: 196784
2013-12-09 22:51:17 +08:00
// CHECK-LABEL: define void @_ZN5test21BC1Ev
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load atomic i8, i8* bitcast (i64* @_ZGVZN5test21BC1EvE1x to i8*) acquire,
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
// CHECK: call i32 @__cxa_guard_acquire(i64* @_ZGVZN5test21BC1EvE1x)
// CHECK: [[T0:%.*]] = call i32 @_ZN5test23fooEv()
// CHECK: store i32 [[T0]], i32* @_ZZN5test21BC1EvE1x,
// CHECK: call void @__cxa_guard_release(i64* @_ZGVZN5test21BC1EvE1x)
// This is just for completeness, because we actually emit this
// using a delegate dtor call.
B::~B() {
static int y = foo();
}
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_ZN5test21BD2Ev(
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: load atomic i8, i8* bitcast (i64* @_ZGVZN5test21BD1EvE1y to i8*) acquire,
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
// CHECK: call i32 @__cxa_guard_acquire(i64* @_ZGVZN5test21BD1EvE1y)
// CHECK: [[T0:%.*]] = call i32 @_ZN5test23fooEv()
// CHECK: store i32 [[T0]], i32* @_ZZN5test21BD1EvE1y,
// CHECK: call void @__cxa_guard_release(i64* @_ZGVZN5test21BD1EvE1y)
Output destructors and constructors in a more natural order. With this patch we output the in the order C2 C1 D2 D1 D0 Which means that a destructor or constructor that call another is output after the callee. This is a bit easier to read IHMO and a tiny bit more efficient as we don't put a decl in DeferredDeclsToEmit. llvm-svn: 196784
2013-12-09 22:51:17 +08:00
// CHECK-LABEL: define void @_ZN5test21BD1Ev(
// CHECK: call void @_ZN5test21BD2Ev(
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
}
// This shouldn't error out.
namespace test3 {
struct A {
A();
~A();
};
struct B : virtual A {
B();
~B();
};
B::B() {
union U { char x; int i; };
static U u = { 'a' };
}
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_ZN5test31BC2Ev(
Output destructors and constructors in a more natural order. With this patch we output the in the order C2 C1 D2 D1 D0 Which means that a destructor or constructor that call another is output after the callee. This is a bit easier to read IHMO and a tiny bit more efficient as we don't put a decl in DeferredDeclsToEmit. llvm-svn: 196784
2013-12-09 22:51:17 +08:00
// CHECK-LABEL: define void @_ZN5test31BC1Ev(
Make sure we unique static-local decls across multiple emissions of the function body, but do so in a way that doesn't make any assumptions about the static local actually having a proper, unique mangling, since apparently we don't do that correctly at all. llvm-svn: 153776
2012-03-31 05:00:39 +08:00
}
Fix a case where we forgot to make a static local variable comdat Sometimes we can provide an initializer for static locals, in which case we sometimes might need to change the type. Changing the type requires making a new LLVM GlobalVariable, and in this codepath we were forgetting to transfer the comdat. Fixes PR23838. Patch by Ivan Garramona. llvm-svn: 242704
2015-07-21 04:35:30 +08:00
// We forgot to set the comdat when replacing the global with a different type.
namespace test4 {
struct HasVTable {
virtual void f();
};
inline HasVTable &useStaticLocal() {
static HasVTable obj;
return obj;
}
void useit() {
useStaticLocal();
}
// CHECK: define linkonce_odr dereferenceable(8) %"struct.test4::HasVTable"* @_ZN5test414useStaticLocalEv()
// CHECK: ret %"struct.test4::HasVTable"* @_ZZN5test414useStaticLocalEvE3obj
}