On 9/4/20 5:39 PM, Marek Polacek wrote:
This patch fixes a long-standing bug in reshape_init_r. Since r209314
we implement DR 1467 which handles list-initialization with a single
initializer of the same type as the target. In this test this causes
a crash in reshape_init_r when we're processing a constructor that has
undergone the DR 1467 transformation.
Take e.g. the
foo({{1, {H{k}}}});
line in the attached test. {H{k}} initializes the field b of H in I.
H{k} is a functional cast, so has TREE_HAS_CONSTRUCTOR set, so is
COMPOUND_LITERAL_P. We perform the DR 1467 transformation and turn
{H{k}} into H{k}. Then we attempt to reshape H{k} again and since
first_initializer_p is null and it's COMPOUND_LITERAL_P, we go here:
else if (COMPOUND_LITERAL_P (stripped_init))
gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
It looks to me like the bug is here:
/* [dcl.init.aggr]
All implicit type conversions (clause _conv_) are considered when
initializing the aggregate member with an initializer from an
initializer-list. If the initializer can initialize a member,
the member is initialized. Otherwise, if the member is itself a
non-empty subaggregate, brace elision is assumed and the
initializer is considered for the initialization of the first
member of the subaggregate. */
if (TREE_CODE (init) != CONSTRUCTOR
/* But don't try this for the first initializer, since that would be
looking through the outermost braces; A a2 = { a1 }; is not a
valid aggregate initialization. */
&& !first_initializer_p
&& (same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE (init))
|| can_convert_arg (type, TREE_TYPE (init), init, LOOKUP_NORMAL,
complain)))
{
d->cur++;
return init;
}
We ought to handle H{k} here, treat it as the initializer for the
member, and not get as far as the code you quote above.
Jason
