Hi!
In this case dwarf2out_decl is called from the FEs with GENERIC but not
yet gimplified expressions in it.
As loc_list_from_tree_1 has an exhaustive list of tree codes it wants to
handle and for checking asserts no other codes makes it in, we should
handle even GENERIC trees that shouldn't be valid in GIMPLE.
The following patch handles COMPOUND_LITERAL_EXPR by hnadling it like the
underlying VAR_DECL temporary.
Bootstrapped/regtested on x86_64-linux and i686-linux, plus verified
the emitted DWARF is correct (but unoptimized, we emit
DW_OP_lit1 DW_OP_lit1 DW_OP_minus
for the upper bound). Ok for trunk?
2021-06-30 Jakub Jelinek <ja...@redhat.com>
PR debug/101266
* dwarf2out.c (loc_list_from_tree_1): Handle COMPOUND_LITERAL_EXPR.
* gcc.dg/pr101266.c: New test.
--- gcc/dwarf2out.c.jj 2021-06-29 11:18:45.789632911 +0200
+++ gcc/dwarf2out.c 2021-06-30 12:58:21.591100184 +0200
@@ -19404,6 +19404,10 @@ loc_list_from_tree_1 (tree loc, int want
case FIX_TRUNC_EXPR:
return 0;
+ case COMPOUND_LITERAL_EXPR:
+ return loc_list_from_tree_1 (COMPOUND_LITERAL_EXPR_DECL (loc),
+ 0, context);
+
default:
/* Leave front-end specific codes as simply unknown. This comes
up, for instance, with the C STMT_EXPR. */
--- gcc/testsuite/gcc.dg/pr101266.c.jj 2021-06-30 13:05:25.355329328 +0200
+++ gcc/testsuite/gcc.dg/pr101266.c 2021-06-30 13:05:19.882404285 +0200
@@ -0,0 +1,8 @@
+/* PR debug/101266 */
+/* { dg-do compile } */
+/* { dg-options "-g -O2" } */
+
+void
+foo (int (*p)[(int){1}])
+{
+}
Jakub
