https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The following fixes the ICE:

--- gcc/cp/constexpr.c.jj       2019-11-16 18:13:28.524822284 +0100
+++ gcc/cp/constexpr.c  2019-11-18 19:38:40.032618830 +0100
@@ -39,7 +39,7 @@ along with GCC; see the file COPYING3.
 static bool verify_constant (tree, bool, bool *, bool *);
 #define VERIFY_CONSTANT(X)                                             \
 do {                                                                   \
-  if (verify_constant ((X), ctx->quiet, non_constant_p, overflow_p)) \
+  if (verify_constant ((X), ctx->quiet, non_constant_p, overflow_p))   \
     return t;                                                          \
  } while (0)

@@ -3405,7 +3405,11 @@ cxx_eval_vec_init_1 (const constexpr_ctx

   tree nelts = get_array_or_vector_nelts (ctx, atype, non_constant_p,
                                          overflow_p);
-  unsigned HOST_WIDE_INT max = tree_to_uhwi (nelts);
+  unsigned HOST_WIDE_INT max;
+  if (verify_constant (nelts, ctx->quiet, non_constant_p, overflow_p))
+    max = 0;
+  else
+    max = tree_to_uhwi (nelts);
   for (i = 0; i < max; ++i)
     {
       tree idx = build_int_cst (size_type_node, i);
--- gcc/testsuite/g++.dg/cpp0x/pr90659.C.jj     2019-11-18 19:41:14.805308816
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr90659.C        2019-11-18 19:43:50.630983085
+0100
@@ -0,0 +1,17 @@
+// PR c++/90659
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+template <typename T>
+void
+foo (int n)
+{
+  T a[n];
+  [=]{ a; };
+}
+
+void
+bar ()
+{
+  foo <double>;
+}

but the testcase still FAILs with -std=gnu++17/2a with weird errors:
/usr/src/gcc/gcc/testsuite/g++.dg/cpp0x/pr90659.C:10:3: error: name '__a' used
in a GNU-style designated initializer for an array
/usr/src/gcc/gcc/testsuite/g++.dg/cpp0x/pr90659.C:10:3: error: cannot convert
'double*' to 'double' in initialization

and e.g. with auto f = [=]{ a; }; instead it still ICEs elsewhere - in
check_initializer.  Having a VLA return from a lambda isn't the best idea...

Reply via email to