Hi!

On this testcase we ICE, because cxx_eval_array_reference calls
build_value_init with ARRAY_TYPE (to get initializer for x[0]).
build_value_init seems to work for arrays of scalars (or arrays of arrays of
scalars etc.) apparently just fine even when processing_template_decl,
if I understand the comment, is it just about the stuff build_value_init
does for CLASS_TYPE_P before calling build_value_init_noctor.
Of course array of classes would be an issue, but we'd still ICE on it
even with the patch, as for ARRAY_TYPE we call build_value_init on its
TREE_TYPE.  And constexprs in that case apparently have all array entries
filled in.

Alternatively, perhaps we could move this gcc_assert down into the if
(CLASS_TYPE_P (type)) { block and change it into just gcc_assert
(!processing_template_decl).

2011-12-06  Jakub Jelinek  <ja...@redhat.com>

        PR c++/51369
        * init.c (build_value_init): Allow array types even when
        processing_template_decl.

        * g++.dg/cpp0x/constexpr-51369.C: New test.

--- gcc/cp/init.c.jj    2011-11-28 17:58:00.000000000 +0100
+++ gcc/cp/init.c       2011-12-06 20:23:25.288799336 +0100
@@ -333,7 +333,8 @@ build_value_init (tree type, tsubst_flag
      constructor.  */
 
   /* The AGGR_INIT_EXPR tweaking below breaks in templates.  */
-  gcc_assert (!processing_template_decl || SCALAR_TYPE_P (type));
+  gcc_assert (!processing_template_decl
+             || (SCALAR_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE));
 
   if (CLASS_TYPE_P (type))
     {
--- gcc/testsuite/g++.dg/cpp0x/constexpr-51369.C.jj     2011-12-06 
20:24:54.542241075 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-51369.C        2011-12-06 
20:24:19.000000000 +0100
@@ -0,0 +1,12 @@
+// PR c++/51369
+// { dg-do compile }
+// { dg-options "-std=c++11" }
+
+constexpr int x[2][2] = {};
+
+template<int>
+void
+foo ()
+{
+  x[0][0];
+}

        Jakub

Reply via email to