Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

[Jason Merrill <jason at redhat dot com>]

On Mon, Mar 26, 2018 at 5:19 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 23/03/2018 13:39, Jason Merrill wrote:
>> On Fri, Mar 23, 2018 at 6:13 AM, Paolo Carlini <paolo.carlini@oracle.com>
>> wrote:
>>>
>>> On 22/03/2018 23:26, Jason Merrill wrote:
>>>>
>>>> On Thu, Mar 22, 2018 at 5:39 PM, Paolo Carlini
>>>> <paolo.carlini@oracle.com>
>>>> wrote:
>>>>>
>>>>> ... with patch ;)
>>>>>
>>>>> If you are curious where the heck that INDIRECT_REF is coming from, is
>>>>> coming from the gimplifier, cp_gimpliify_expr, via build_vec_init.
>>>>> Grrr.
>>>>
>>>> Hmm, maybe build_vec_init should call itself directly rather than via
>>>> build_aggr_init in the case of multidimensional arrays.
>>>
>>> Yes, arranging things like that seems doable. However, yesterday, while
>>> fiddling with the idea and instrumenting the code with some gcc_asserts,
>>> I
>>> noticed that we have yet another tree code to handle, TARGET_EXPR, as in
>>> lines #41, #47, #56 of ext/complit12.C, and in that case build_aggr_init
>>> is
>>> simply called by check_initializer via build_aggr_init_full_exprs, the
>>> "normal" path. Well, unless we want to adjust/reject complit12.C too,
>>> which
>>> clang rejects, in fact with errors on lines #19 and #29 too. The below
>>> passes testing.
>>
>> I think I'd like to allow TARGET_EXPR here, with a comment about
>> compound literals, but avoid INDIRECT_REF with that build_vec_init
>> change.
>
> I see. Having run the full testsuite a number of times with additional
> gcc_asserts, I'm very confident that something as simple as the below is
> fine, at least as far as the testsuite + variants of lambda-array.C is
> concerned. In it I'm also proposing a gcc_assert verifying that the very
> idea of not using any diagnostic conditional makes sense for the internally
> generated INDIRECT_REFs: in the existing build_aggr_init if the types were
> different from_array would be zero and, for INDIRECT_REF as init, the
> condition true.

Your build_aggr_init change is OK, but I had in mind something more
general in build_vec_init:

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index ff52c42c1ad..d689390d117 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -4367,7 +4367,10 @@ build_vec_init (tree base, tree maxindex, tree init,
 	  else
 	    from = NULL_TREE;
 
-	  if (from_array == 2)
+	  if (TREE_CODE (type) == ARRAY_TYPE)
+	    elt_init = build_vec_init (to, NULL_TREE, from, /*val_init*/false,
+				       from_array, complain);
+	  else if (from_array == 2)
 	    elt_init = cp_build_modify_expr (input_location, to, NOP_EXPR,
 					     from, complain);
 	  else if (type_build_ctor_call (type))