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/cxx0x-initializer-stdinitia...

357 lines
11 KiB
C++
Raw Normal View History

Provide fixed target triples to make test results consistent across ARM hosts. Patch by David Tweed, review by myself and John McCall. llvm-svn: 163564
2012-09-11 07:06:08 +08:00
// RUN: %clang_cc1 -std=c++11 -S -triple x86_64-none-linux-gnu -emit-llvm -o - %s | FileCheck %s
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
namespace std {
typedef decltype(sizeof(int)) size_t;
// libc++'s implementation
template <class _E>
class initializer_list
{
const _E* __begin_;
size_t __size_;
initializer_list(const _E* __b, size_t __s)
: __begin_(__b),
__size_(__s)
{}
public:
typedef _E value_type;
typedef const _E& reference;
typedef const _E& const_reference;
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
initializer_list() : __begin_(nullptr), __size_(0) {}
size_t size() const {return __size_;}
const _E* begin() const {return __begin_;}
const _E* end() const {return __begin_ + __size_;}
};
}
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
struct destroyme1 {
~destroyme1();
};
struct destroyme2 {
~destroyme2();
};
struct witharg1 {
witharg1(const destroyme1&);
~witharg1();
};
struct wantslist1 {
wantslist1(std::initializer_list<destroyme1>);
~wantslist1();
};
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: @_ZGR15globalInitList1 = private constant [3 x i32] [i32 1, i32 2, i32 3]
// CHECK: @globalInitList1 = global %{{[^ ]+}} { i32* getelementptr inbounds ([3 x i32]* @_ZGR15globalInitList1, i32 0, i32 0), i{{32|64}} 3 }
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
std::initializer_list<int> globalInitList1 = {1, 2, 3};
CodeGen support for function-local static thread_local variables with non-constant constructors or non-trivial destructors. Plus bugfixes for thread_local references bound to temporaries (the temporaries themselves are lifetime-extended to become thread_local), and the corresponding case for std::initializer_list. llvm-svn: 179496
2013-04-15 07:01:42 +08:00
namespace thread_local_global_array {
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// FIXME: We should be able to constant-evaluate this even though the
// initializer is not a constant expression (pointers to thread_local
// objects aren't really a problem).
//
// CHECK: @_ZN25thread_local_global_array1xE = thread_local global
// CHECK: @_ZGRN25thread_local_global_array1xE = private thread_local global [4 x i32]
CodeGen support for function-local static thread_local variables with non-constant constructors or non-trivial destructors. Plus bugfixes for thread_local references bound to temporaries (the temporaries themselves are lifetime-extended to become thread_local), and the corresponding case for std::initializer_list. llvm-svn: 179496
2013-04-15 07:01:42 +08:00
std::initializer_list<int> thread_local x = { 1, 2, 3, 4 };
}
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: @globalInitList2 = global %{{[^ ]+}} zeroinitializer
// CHECK: @_ZGR15globalInitList2 = private global [2 x %[[WITHARG:[^ ]*]]] zeroinitializer
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
// CHECK: appending global
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// thread_local initializer:
// CHECK: define internal void
// CHECK: store i32 1, i32* getelementptr inbounds ([4 x i32]* @_ZGRN25thread_local_global_array1xE, i64 0, i64 0)
// CHECK: store i32 2, i32* getelementptr inbounds ([4 x i32]* @_ZGRN25thread_local_global_array1xE, i64 0, i64 1)
// CHECK: store i32 3, i32* getelementptr inbounds ([4 x i32]* @_ZGRN25thread_local_global_array1xE, i64 0, i64 2)
// CHECK: store i32 4, i32* getelementptr inbounds ([4 x i32]* @_ZGRN25thread_local_global_array1xE, i64 0, i64 3)
// CHECK: store i32* getelementptr inbounds ([4 x i32]* @_ZGRN25thread_local_global_array1xE, i64 0, i64 0),
// CHECK: i32** getelementptr inbounds ({{.*}}* @_ZN25thread_local_global_array1xE, i32 0, i32 0), align 8
// CHECK: store i64 4, i64* getelementptr inbounds ({{.*}}* @_ZN25thread_local_global_array1xE, i32 0, i32 1), align 8
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
// CHECK: define internal void
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: call void @_ZN8witharg1C1ERK10destroyme1(%[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]]* @_ZGR15globalInitList2, i{{32|64}} 0, i{{32|64}} 0
// CHECK: call void @_ZN8witharg1C1ERK10destroyme1(%[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]]* @_ZGR15globalInitList2, i{{32|64}} 0, i{{32|64}} 1
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
// CHECK: __cxa_atexit
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: store %[[WITHARG]]* getelementptr inbounds ([2 x %[[WITHARG]]]* @_ZGR15globalInitList2, i64 0, i64 0),
// CHECK: %[[WITHARG]]** getelementptr inbounds (%{{.*}}* @globalInitList2, i32 0, i32 0), align 8
// CHECK: store i64 2, i64* getelementptr inbounds (%{{.*}}* @globalInitList2, i32 0, i32 1), align 8
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
// CHECK: call void @_ZN10destroyme1D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
std::initializer_list<witharg1> globalInitList2 = {
witharg1(destroyme1()), witharg1(destroyme1())
};
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
void fn1(int i) {
// CHECK: define void @_Z3fn1i
// temporary array
// CHECK: [[array:%[^ ]+]] = alloca [3 x i32]
// CHECK: getelementptr inbounds [3 x i32]* [[array]], i{{32|64}} 0
// CHECK-NEXT: store i32 1, i32*
// CHECK-NEXT: getelementptr
// CHECK-NEXT: store
// CHECK-NEXT: getelementptr
// CHECK-NEXT: load
// CHECK-NEXT: store
// init the list
// CHECK-NEXT: getelementptr
// CHECK-NEXT: getelementptr inbounds [3 x i32]*
// CHECK-NEXT: store i32*
// CHECK-NEXT: getelementptr
// CHECK-NEXT: store i{{32|64}} 3
std::initializer_list<int> intlist{1, 2, i};
}
void fn2() {
// CHECK: define void @_Z3fn2v
void target(std::initializer_list<destroyme1>);
// objects should be destroyed before dm2, after call returns
Add a testcase to show that temporaries from the initializer list are destroyed correctly. llvm-svn: 150924
2012-02-19 20:27:51 +08:00
// CHECK: call void @_Z6targetSt16initializer_listI10destroyme1E
Basic code generation support for std::initializer_list. We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
2012-02-17 16:42:25 +08:00
target({ destroyme1(), destroyme1() });
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn3() {
// CHECK: define void @_Z3fn3v
// objects should be destroyed after dm2
auto list = { destroyme1(), destroyme1() };
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
}
Add a testcase to show that temporaries from the initializer list are destroyed correctly. llvm-svn: 150924
2012-02-19 20:27:51 +08:00
void fn4() {
// CHECK: define void @_Z3fn4v
void target(std::initializer_list<witharg1>);
// objects should be destroyed before dm2, after call returns
// CHECK: call void @_ZN8witharg1C1ERK10destroyme1
// CHECK: call void @_Z6targetSt16initializer_listI8witharg1E
target({ witharg1(destroyme1()), witharg1(destroyme1()) });
// CHECK: call void @_ZN8witharg1D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn5() {
// CHECK: define void @_Z3fn5v
// temps should be destroyed before dm2
// objects should be destroyed after dm2
// CHECK: call void @_ZN8witharg1C1ERK10destroyme1
auto list = { witharg1(destroyme1()), witharg1(destroyme1()) };
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN8witharg1D1Ev
}
Add a testcase for using objects with list-constructors, and fix a Sema crash by repeating an old hack. llvm-svn: 150925
2012-02-19 20:27:56 +08:00
void fn6() {
// CHECK: define void @_Z3fn6v
void target(const wantslist1&);
// objects should be destroyed before dm2, after call returns
// CHECK: call void @_ZN10wantslist1C1ESt16initializer_listI10destroyme1E
// CHECK: call void @_Z6targetRK10wantslist1
target({ destroyme1(), destroyme1() });
// CHECK: call void @_ZN10wantslist1D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn7() {
// CHECK: define void @_Z3fn7v
// temps should be destroyed before dm2
// object should be destroyed after dm2
// CHECK: call void @_ZN10wantslist1C1ESt16initializer_listI10destroyme1E
wantslist1 wl = { destroyme1(), destroyme1() };
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10wantslist1D1Ev
}
Get recursive initializer lists to work and add a test. Codegen of std::initializer_list is now complete. Onward to array new. llvm-svn: 150926
2012-02-19 20:28:02 +08:00
void fn8() {
// CHECK: define void @_Z3fn8v
void target(std::initializer_list<std::initializer_list<destroyme1>>);
// objects should be destroyed before dm2, after call returns
// CHECK: call void @_Z6targetSt16initializer_listIS_I10destroyme1EE
std::initializer_list<destroyme1> inner;
target({ inner, { destroyme1() } });
// CHECK: call void @_ZN10destroyme1D1Ev
// Only one destroy loop, since only one inner init list is directly inited.
// CHECK-NOT: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
void fn9() {
// CHECK: define void @_Z3fn9v
// objects should be destroyed after dm2
std::initializer_list<destroyme1> inner;
std::initializer_list<std::initializer_list<destroyme1>> list =
{ inner, { destroyme1() } };
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
// Only one destroy loop, since only one inner init list is directly inited.
// CHECK-NOT: call void @_ZN10destroyme1D1Ev
// CHECK: ret void
}
Make std::initializer_list member initializers 'work'. llvm-svn: 150930
2012-02-19 23:41:54 +08:00
struct haslist1 {
std::initializer_list<int> il;
haslist1();
};
// CHECK: define void @_ZN8haslist1C2Ev
haslist1::haslist1()
// CHECK: alloca [3 x i32]
// CHECK: store i32 1
// CHECK: store i32 2
// CHECK: store i32 3
// CHECK: store i{{32|64}} 3
: il{1, 2, 3}
{
destroyme2 dm2;
}
struct haslist2 {
std::initializer_list<destroyme1> il;
haslist2();
};
// CHECK: define void @_ZN8haslist2C2Ev
haslist2::haslist2()
: il{destroyme1(), destroyme1()}
{
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
// CHECK: call void @_ZN10destroyme1D1Ev
}
Make heap-allocation of std::initializer_list 'work'. llvm-svn: 150931
2012-02-20 00:03:09 +08:00
void fn10() {
// CHECK: define void @_Z4fn10v
// CHECK: alloca [3 x i32]
Harden test against for operator new(unsigned int). llvm-svn: 150932
2012-02-20 00:20:58 +08:00
// CHECK: call noalias i8* @_Znw{{[jm]}}
Make heap-allocation of std::initializer_list 'work'. llvm-svn: 150931
2012-02-20 00:03:09 +08:00
// CHECK: store i32 1
// CHECK: store i32 2
// CHECK: store i32 3
// CHECK: store i32*
// CHECK: store i{{32|64}} 3
(void) new std::initializer_list<int> {1, 2, 3};
}
void fn11() {
// CHECK: define void @_Z4fn11v
(void) new std::initializer_list<destroyme1> {destroyme1(), destroyme1()};
// CHECK: call void @_ZN10destroyme1D1Ev
destroyme2 dm2;
// CHECK: call void @_ZN10destroyme2D1Ev
}
If the element type of an initializer list has a destructor, make sure we check it. Fixes PR12178. llvm-svn: 152048
2012-03-06 03:35:43 +08:00
namespace PR12178 {
struct string {
string(int);
~string();
};
struct pair {
string a;
int b;
};
struct map {
map(std::initializer_list<pair>);
};
map m{ {1, 2}, {3, 4} };
}
<rdar://problem/13325066> Destroy std::initializer_list temporaries whose lifetime has been extended by reference binding. llvm-svn: 178939
2013-04-06 08:46:20 +08:00
namespace rdar13325066 {
struct X { ~X(); };
// CHECK: define void @_ZN12rdar133250664loopERNS_1XES1_
void loop(X &x1, X &x2) {
// CHECK: br label
// CHECK: br i1
// CHECK: br label
// CHECK call void @_ZN12rdar133250661XD1Ev
// CHECK: br label
// CHECK: br label
// CHECK: call void @_ZN12rdar133250661XD1Ev
// CHECK: br i1
// CHECK: br label
// CHECK: ret void
for (X x : { x1, x2 }) { }
}
}
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
namespace dtors {
struct S {
S();
~S();
};
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
void z();
// CHECK: define void @_ZN5dtors1fEv(
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
void f() {
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: call void @_ZN5dtors1SC1Ev(%"struct.dtors::S"* %arrayinit.begin)
// CHECK: call void @_ZN5dtors1SC1Ev(%"struct.dtors::S"* %arrayinit.element)
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
std::initializer_list<S>{ S(), S() };
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// Destruction loop for underlying array.
// CHECK: br label
// CHECK: call void @_ZN5dtors1SD1Ev(
// CHECK: br i1
// CHECK: call void @_ZN5dtors1zEv(
z();
// CHECK-NOT: call void @_ZN5dtors1SD1Ev(
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
}
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: define void @_ZN5dtors1gEv(
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
void g() {
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// CHECK: call void @_ZN5dtors1SC1Ev(%"struct.dtors::S"* %arrayinit.begin)
// CHECK: call void @_ZN5dtors1SC1Ev(%"struct.dtors::S"* %arrayinit.element)
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
auto x = std::initializer_list<S>{ S(), S() };
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
// Destruction loop for underlying array.
// CHECK: br label
// CHECK: call void @_ZN5dtors1SD1Ev(
// CHECK: br i1
// CHECK: call void @_ZN5dtors1zEv(
z();
// CHECK-NOT: call void @_ZN5dtors1SD1Ev(
}
// CHECK: define void @_ZN5dtors1hEv(
void h() {
// CHECK: call void @_ZN5dtors1SC1Ev(%"struct.dtors::S"* %arrayinit.begin)
// CHECK: call void @_ZN5dtors1SC1Ev(%"struct.dtors::S"* %arrayinit.element)
std::initializer_list<S> x = { S(), S() };
// CHECK-NOT: call void @_ZN5dtors1SD1Ev(
// CHECK: call void @_ZN5dtors1zEv(
z();
// Destruction loop for underlying array.
// CHECK: br label
// CHECK: call void @_ZN5dtors1SD1Ev(
// CHECK: br i1
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
}
Fix assert on temporary std::initializer_list. llvm-svn: 182615
2013-05-24 05:54:14 +08:00
}