]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: ICE with RANGE_EXPR and array init [PR109431]
authorMarek Polacek <polacek@redhat.com>
Thu, 27 Feb 2025 22:42:49 +0000 (17:42 -0500)
committerMarek Polacek <polacek@redhat.com>
Tue, 4 Mar 2025 14:25:54 +0000 (09:25 -0500)
commit173cf7c9b8c0d61bb2cb0bd3a9e3150b393ab59a
tree3eced7ff97a6dd41df66a2ba544a9fe503e74e41
parentd883f3233c4b7e0dce52539a12dfcccc8aff43e4
c++: ICE with RANGE_EXPR and array init [PR109431]

We crash because we generate

  {[0 ... 1]={.low=0, .high=1}, [1]={.low=0, .high=1}}

which output_constructor_regular_field doesn't want to see.  This
happens since r9-1483: process_init_constructor_array can now create
a RANGE_EXPR.  But the bug isn't in that patch; the problem is that
build_vec_init doesn't handle RANGE_EXPRs.

build_vec_init has a FOR_EACH_CONSTRUCTOR_ELT loop which populates
const_vec.  In this case it loops over the elements of

  {[0 ... 1]={.low=0, .high=1}}

but assumes that each element initializes one element.  So after the
loop num_initialized_elts was 1, and then below:

              HOST_WIDE_INT last = tree_to_shwi (maxindex);
              if (num_initialized_elts <= last)
                {
                  tree field = size_int (num_initialized_elts);
                  if (num_initialized_elts != last)
                    field = build2 (RANGE_EXPR, sizetype, field,
                                    size_int (last));
                  CONSTRUCTOR_APPEND_ELT (const_vec, field, e);
                }

we added the extra initializer.

It seemed convenient to use range_expr_nelts like below.

PR c++/109431

gcc/cp/ChangeLog:

* cp-tree.h (range_expr_nelts): Declare.
* init.cc (build_vec_init): If the CONSTRUCTOR's index is a
RANGE_EXPR, use range_expr_nelts to count how many elements
were initialized.

gcc/testsuite/ChangeLog:

* g++.dg/init/array67.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
gcc/cp/cp-tree.h
gcc/cp/init.cc
gcc/testsuite/g++.dg/init/array67.C [new file with mode: 0644]