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/compound-literals.cpp

86 lines
3.2 KiB
C++
Raw Normal View History

CodeGen: Compound literals with funny types shouldn't crash CodeGen assumed that a compound literal with array type should have a corresponding LLVM IR array type. We had two bugs in this area: - Zero sized arrays in compound literals would lead to the creation of an opaque type. This is unnecessary, we should just create an array type with a bound of zero. - Funny record types (like unions) lead to exotic IR types for compound literals. In this case, CodeGen must be prepared to deal with the possibility that it might not have an array IR type. This fixes PR21912. llvm-svn: 224219
2014-12-14 20:16:43 +08:00
// RUN: %clang_cc1 -std=c++11 -triple armv7-none-eabi -emit-llvm -o - %s | FileCheck %s
Implement proper support for generating code for compound literals in C++, which means: - binding the temporary as needed in Sema, so that we generate the appropriate call to the destructor, and - emitting the compound literal into the appropriate location for the aggregate, rather than trying to emit it as a temporary and memcpy() it. Fixes PR10138 / <rdar://problem/9615901>. llvm-svn: 133235
2011-06-17 12:59:12 +08:00
struct X {
X();
X(const X&);
X(const char*);
~X();
};
struct Y {
int i;
X x;
};
DR1213: element access on an array xvalue or prvalue produces an xvalue. In the latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
2016-12-05 15:49:14 +08:00
// CHECK: @.compoundliteral = internal global [5 x i32] [i32 1, i32 2, i32 3, i32 4, i32 5], align 4
// CHECK: @q = global i32* getelementptr inbounds ([5 x i32], [5 x i32]* @.compoundliteral, i32 0, i32 0), align 4
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 i32 @_Z1fv()
Implement proper support for generating code for compound literals in C++, which means: - binding the temporary as needed in Sema, so that we generate the appropriate call to the destructor, and - emitting the compound literal into the appropriate location for the aggregate, rather than trying to emit it as a temporary and memcpy() it. Fixes PR10138 / <rdar://problem/9615901>. llvm-svn: 133235
2011-06-17 12:59:12 +08:00
int f() {
// CHECK: [[LVALUE:%[a-z0-9.]+]] = alloca
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK-NEXT: [[I:%[a-z0-9]+]] = getelementptr inbounds {{.*}}, {{.*}}* [[LVALUE]], i32 0, i32 0
Implement proper support for generating code for compound literals in C++, which means: - binding the temporary as needed in Sema, so that we generate the appropriate call to the destructor, and - emitting the compound literal into the appropriate location for the aggregate, rather than trying to emit it as a temporary and memcpy() it. Fixes PR10138 / <rdar://problem/9615901>. llvm-svn: 133235
2011-06-17 12:59:12 +08:00
// CHECK-NEXT: store i32 17, i32* [[I]]
// CHECK-NEXT: [[X:%[a-z0-9]+]] = getelementptr inbounds {{.*}} [[LVALUE]], i32 0, i32 1
Fix ABI dependent tests by providing an explicit target triple. Patch by Joey Gouly. llvm-svn: 164239
2012-09-20 02:46:03 +08:00
// CHECK-NEXT: call %struct.X* @_ZN1XC1EPKc({{.*}}[[X]]
Implement proper support for generating code for compound literals in C++, which means: - binding the temporary as needed in Sema, so that we generate the appropriate call to the destructor, and - emitting the compound literal into the appropriate location for the aggregate, rather than trying to emit it as a temporary and memcpy() it. Fixes PR10138 / <rdar://problem/9615901>. llvm-svn: 133235
2011-06-17 12:59:12 +08:00
// CHECK-NEXT: [[I:%[a-z0-9]+]] = getelementptr inbounds {{.*}} [[LVALUE]], i32 0, i32 0
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK-NEXT: [[RESULT:%[a-z0-9]+]] = load i32, i32*
Fix ABI dependent tests by providing an explicit target triple. Patch by Joey Gouly. llvm-svn: 164239
2012-09-20 02:46:03 +08:00
// CHECK-NEXT: call %struct.Y* @_ZN1YD1Ev
Implement proper support for generating code for compound literals in C++, which means: - binding the temporary as needed in Sema, so that we generate the appropriate call to the destructor, and - emitting the compound literal into the appropriate location for the aggregate, rather than trying to emit it as a temporary and memcpy() it. Fixes PR10138 / <rdar://problem/9615901>. llvm-svn: 133235
2011-06-17 12:59:12 +08:00
// CHECK-NEXT: ret i32 [[RESULT]]
return ((Y){17, "seventeen"}).i;
}
When reference binding array rvalues, such as those created by compound literals of array type, materialise a temporary. llvm-svn: 144483
2011-11-13 08:51:30 +08:00
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 i32 @_Z1gv()
When reference binding array rvalues, such as those created by compound literals of array type, materialise a temporary. llvm-svn: 144483
2011-11-13 08:51:30 +08:00
int g() {
Update test case for r234543. llvm-svn: 234544
2015-04-10 06:54:53 +08:00
// CHECK: store [2 x i32]* %{{[a-z0-9.]+}}, [2 x i32]** [[V:%[a-z0-9.]+]]
When reference binding array rvalues, such as those created by compound literals of array type, materialise a temporary. llvm-svn: 144483
2011-11-13 08:51:30 +08:00
const int (&v)[2] = (int [2]) {1,2};
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK: [[A:%[a-z0-9.]+]] = load [2 x i32]*, [2 x i32]** [[V]]
Update Clang tests to handle explicitly typed gep changes in LLVM. llvm-svn: 230783
2015-02-28 03:18:17 +08:00
// CHECK-NEXT: [[A0ADDR:%[a-z0-9.]+]] = getelementptr inbounds [2 x i32], [2 x i32]* [[A]], i32 0, {{.*}} 0
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK-NEXT: [[A0:%[a-z0-9.]+]] = load i32, i32* [[A0ADDR]]
When reference binding array rvalues, such as those created by compound literals of array type, materialise a temporary. llvm-svn: 144483
2011-11-13 08:51:30 +08:00
// CHECK-NEXT: ret i32 [[A0]]
return v[0];
}
Use static storage duration for file-scope compound literals, even when they appear in non-constant initializers in C++. llvm-svn: 145087
2011-11-23 06:48:32 +08:00
DR616, and part of P0135R1: member access (or pointer-to-member access) on a temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
2016-12-03 09:14:32 +08:00
// GCC's compound-literals-in-C++ extension lifetime-extends a compound literal
// (or a C++11 list-initialized temporary!) if:
// - it is at global scope
// - it has array type
// - it has a constant initializer
Use static storage duration for file-scope compound literals, even when they appear in non-constant initializers in C++. llvm-svn: 145087
2011-11-23 06:48:32 +08:00
struct Z { int i[3]; };
int *p = (Z){ {1, 2, 3} }.i;
// CHECK: define {{.*}}__cxx_global_var_init()
DR616, and part of P0135R1: member access (or pointer-to-member access) on a temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
2016-12-03 09:14:32 +08:00
// CHECK: alloca %struct.Z
// CHECK: store i32* %{{.*}}, i32** @p
CodeGen: Compound literals with funny types shouldn't crash CodeGen assumed that a compound literal with array type should have a corresponding LLVM IR array type. We had two bugs in this area: - Zero sized arrays in compound literals would lead to the creation of an opaque type. This is unnecessary, we should just create an array type with a bound of zero. - Funny record types (like unions) lead to exotic IR types for compound literals. In this case, CodeGen must be prepared to deal with the possibility that it might not have an array IR type. This fixes PR21912. llvm-svn: 224219
2014-12-14 20:16:43 +08:00
DR616, and part of P0135R1: member access (or pointer-to-member access) on a temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
2016-12-03 09:14:32 +08:00
int *q = (int [5]){1, 2, 3, 4, 5};
DR1213: element access on an array xvalue or prvalue produces an xvalue. In the latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
2016-12-05 15:49:14 +08:00
// (constant initialization, checked above)
extern int n;
int *r = (int [5]){1, 2, 3, 4, 5} + n;
DR616, and part of P0135R1: member access (or pointer-to-member access) on a temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
2016-12-03 09:14:32 +08:00
// CHECK-LABEL: define {{.*}}__cxx_global_var_init.1()
DR1213: element access on an array xvalue or prvalue produces an xvalue. In the latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
2016-12-05 15:49:14 +08:00
// CHECK: %[[PTR:.*]] = getelementptr inbounds i32, i32* getelementptr inbounds ([5 x i32], [5 x i32]* @.compoundliteral.2, i32 0, i32 0), i32 %
// CHECK: store i32* %[[PTR]], i32** @r
CodeGen: Compound literals with funny types shouldn't crash CodeGen assumed that a compound literal with array type should have a corresponding LLVM IR array type. We had two bugs in this area: - Zero sized arrays in compound literals would lead to the creation of an opaque type. This is unnecessary, we should just create an array type with a bound of zero. - Funny record types (like unions) lead to exotic IR types for compound literals. In this case, CodeGen must be prepared to deal with the possibility that it might not have an array IR type. This fixes PR21912. llvm-svn: 224219
2014-12-14 20:16:43 +08:00
DR1213: element access on an array xvalue or prvalue produces an xvalue. In the latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
2016-12-05 15:49:14 +08:00
int *PR21912_1 = (int []){} + n;
// CHECK-LABEL: define {{.*}}__cxx_global_var_init.3()
// CHECK: %[[PTR:.*]] = getelementptr inbounds i32, i32* getelementptr inbounds ([0 x i32], [0 x i32]* @.compoundliteral.4, i32 0, i32 0), i32 %
// CHECK: store i32* %[[PTR]], i32** @PR21912_1
CodeGen: Compound literals with funny types shouldn't crash CodeGen assumed that a compound literal with array type should have a corresponding LLVM IR array type. We had two bugs in this area: - Zero sized arrays in compound literals would lead to the creation of an opaque type. This is unnecessary, we should just create an array type with a bound of zero. - Funny record types (like unions) lead to exotic IR types for compound literals. In this case, CodeGen must be prepared to deal with the possibility that it might not have an array IR type. This fixes PR21912. llvm-svn: 224219
2014-12-14 20:16:43 +08:00
union PR21912Ty {
long long l;
double d;
};
DR1213: element access on an array xvalue or prvalue produces an xvalue. In the latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
2016-12-05 15:49:14 +08:00
union PR21912Ty *PR21912_2 = (union PR21912Ty[]){{.d = 2.0}, {.l = 3}} + n;
// CHECK-LABEL: define {{.*}}__cxx_global_var_init.5()
// CHECK: %[[PTR:.*]] = getelementptr inbounds %union.PR21912Ty, %union.PR21912Ty* getelementptr inbounds ([2 x %union.PR21912Ty], [2 x %union.PR21912Ty]* bitcast (<{ { double }, %union.PR21912Ty }>* @.compoundliteral.6 to [2 x %union.PR21912Ty]*), i32 0, i32 0), i32 %
// CHECK: store %union.PR21912Ty* %[[PTR]], %union.PR21912Ty** @PR21912_2, align 4
A compound literal within a global lambda or block is still within the body of a function for the purposes of computing its storage duration and deciding whether its initializer must be constant. There are a number of problems in our current treatment of compound literals. C specifies that a compound literal yields an l-value referring to an object with either static or automatic storage duration, depending on where it was written; in the latter case, the literal object has a lifetime tied to the enclosing scope (much like an ObjC block), not the enclosing full-expression. To get these semantics fully correct in our current design, we would need to collect compound literals on the ExprWithCleanups, just like we do with ObjC blocks; we would probably also want to identify literals like we do with materialized temporaries. But it gets stranger; GCC adds compound literals to C++ as an extension, but makes them r-values, which are generally assumed to have temporary storage duration. Ignoring destructor ordering, the difference only matters if the object's address escapes the full-expression, which for an r-value can only happen with reference binding (which extends temporaries) or array-to-pointer decay (which does not). GCC then attempts to lock down on array-to-pointer decay in ad hoc ways. Arguably a far superior language solution for C++ (and perhaps even array r-values in C, which can occur in other ways) would be to propagate lifetime extension through array-to-pointer decay, so that initializing a pointer object to a decayed r-value array extends the lifetime of the complete object containing the array. But this would be a major change in semantics which arguably ought to be blessed by the committee(s). Anyway, I'm not fixing any of that in this patch; I did try, but it got out of hand. Fixes rdar://28949016. llvm-svn: 285643
2016-11-01 05:56:26 +08:00
// This compound literal should have local scope.
int computed_with_lambda = [] {
int *array = (int[]) { 1, 3, 5, 7 };
return array[0];
}();
// CHECK-LABEL: define internal i32 @{{.*}}clEv
// CHECK: alloca [4 x i32]