procyberian/gcc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

re PR c++/59886 (C++ array init optimization results in RANGE_EXPRs in assignments)

Browse source 
PR c++/59886
	PR c++/59659
	* typeck2.c (process_init_constructor_array): Don't create
	RANGE_EXPR yet.

From-SVN: r207051
This commit is contained in:
Jason Merrill 2014-01-24 11:47:54 -05:00 • committed by Jason Merrill
parent 2cbf3dd796
commit 114bf2605d
3 changed files with 45 additions and 34 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
gcc/cp/ChangeLog
View file

@ -1,3 +1,10 @@
2014-01-24 Jason Merrill <jason@redhat.com>
PR c++/59886
PR c++/59659
* typeck2.c (process_init_constructor_array): Don't create
RANGE_EXPR yet.
2014-01-24 Jakub Jelinek <jakub@redhat.com>
* typeck2.c (split_nonconstant_init_1): Fix num_split_elts

66
gcc/cp/typeck2.c
View file

@ -1201,42 +1201,40 @@ process_init_constructor_array (tree type, tree init,
flags |= picflag_from_initializer (ce->value);
}
/* No more initializers. If the array is unbounded, or we've initialized
all the elements, we are done. Otherwise, we must add initializers
ourselves. */
if (!unbounded && i < len)
{
tree next;
/* No more initializers. If the array is unbounded, we are done. Otherwise,
we must add initializers ourselves. */
if (!unbounded)
for (; i < len; ++i)
{
tree next;
if (type_build_ctor_call (TREE_TYPE (type)))
{
/* If this type needs constructors run for default-initialization,
we can't rely on the back end to do it for us, so make the
initialization explicit by list-initializing from {}. */
next = build_constructor (init_list_type_node, NULL);
next = massage_init_elt (TREE_TYPE (type), next, complain);
if (initializer_zerop (next))
/* The default zero-initialization is fine for us; don't
add anything to the CONSTRUCTOR. */
next = NULL_TREE;
}
else if (!zero_init_p (TREE_TYPE (type)))
next = build_zero_init (TREE_TYPE (type),
/*nelts=*/NULL_TREE,
/*static_storage_p=*/false);
else
/* The default zero-initialization is fine for us; don't
add anything to the CONSTRUCTOR. */
next = NULL_TREE;
if (type_build_ctor_call (TREE_TYPE (type)))
{
/* If this type needs constructors run for default-initialization,
we can't rely on the back end to do it for us, so make the
initialization explicit by list-initializing from {}. */
next = build_constructor (init_list_type_node, NULL);
next = massage_init_elt (TREE_TYPE (type), next, complain);
if (initializer_zerop (next))
/* The default zero-initialization is fine for us; don't
add anything to the CONSTRUCTOR. */
next = NULL_TREE;
}
else if (!zero_init_p (TREE_TYPE (type)))
next = build_zero_init (TREE_TYPE (type),
/*nelts=*/NULL_TREE,
/*static_storage_p=*/false);
else
/* The default zero-initialization is fine for us; don't
add anything to the CONSTRUCTOR. */
next = NULL_TREE;
if (next)
{
flags |= picflag_from_initializer (next);
tree index = build2 (RANGE_EXPR, sizetype, size_int (i),
size_int (len - 1));
CONSTRUCTOR_APPEND_ELT (v, index, next);
}
}
if (next)
{
flags |= picflag_from_initializer (next);
CONSTRUCTOR_APPEND_ELT (v, size_int (i), next);
}
}
CONSTRUCTOR_ELTS (init) = v;
return flags;

6
gcc/testsuite/g++.dg/init/aggr10.C Normal file
View file

@ -0,0 +1,6 @@
// PR c++/59886
struct A { A (); ~A (); };
struct B { A b[4]; };
struct C { B c[5]; };
const C e = {};