We went into build_vec_init because we're dealing with a VLA, but then
build_vec_init thought it was safe to just build an INIT_EXPR because the
outer dimension is constant. Nope.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Check for vla element type.
gcc/testsuite/ChangeLog:
* g++.dg/ext/vla24.C: New.
---
gcc/cp/init.cc | 1 +
gcc/testsuite/g++.dg/ext/vla24.C | 7 +++++++
2 files changed, 8 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/ext/vla24.C
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 7575597c8fd..08767679dd4 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -4395,6 +4395,7 @@ build_vec_init (tree base, tree maxindex, tree init,
if (init
&& TREE_CODE (atype) == ARRAY_TYPE
&& TREE_CONSTANT (maxindex)
+ && !vla_type_p (type)
&& (from_array == 2
? vec_copy_assign_is_trivial (inner_elt_type, init)
: !TYPE_NEEDS_CONSTRUCTING (type))
diff --git a/gcc/testsuite/g++.dg/ext/vla24.C b/gcc/testsuite/g++.dg/ext/vla24.C
new file mode 100644
index 00000000000..0a99c003ffb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/vla24.C
@@ -0,0 +1,7 @@
+// PR c++/58646
+// { dg-additional-options -Wno-vla }
+
+void foo(int n)
+{
+ int a[2][n] = {};
+}
base-commit: bec69ac548b0f37b41d07082d6ee52b52d356536
--
2.27.0
