public inbox for
 help / color / mirror / Atom feed
From: Marek Polacek <>
To: Jason Merrill <>
Cc: GCC Patches <>
Subject: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]
Date: Wed, 12 Oct 2022 12:27:34 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote:
> On 10/11/22 16:00, Marek Polacek wrote:
> > Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
> > while processing the default argument in this test.
> Hmm, why are we calling cxx_eval_vec_init during parsing of the default
> argument?  In particular, any expansion that depends on the enclosing
> function context should be deferred until the default arg is used by a call.

I think this is part of the semantic constraints checking [dcl.fct.default]/5
talks about, as in, this doesn't compile even though the default argument is
not executed:

struct S {
  S() = delete;
void foo (S = S()) { }
In the test below we parse '= MyVector<1>()' and end up calling mark_used
on the implicit "constexpr MyVector<1>::MyVector() noexcept (<uninstantiated>)"
ctor.  mark_used calls maybe_instantiate_noexcept.  Since the ctor has
a DEFERRED_NOEXCEPT, we have to figure out if the ctor should be noexcept
or not using get_defaulted_eh_spec.  That means walking the members of
MyVector.  Thus we reach
  /* Core 1351: If the field has an NSDMI that could throw, the
     default constructor is noexcept(false).  */
and call get_nsdmi on 'data'.  There we digest its initializer which is {}.
massage_init_elt calls digest_init_r on the {} and produces
  TARGET_EXPR <D.2518, <<< Unknown tree: vec_init_expr
    {} >>>>
and the subsequent fold_non_dependent_init leads to cxx_eval_vec_init
-> expand_vec_init_expr.

I think this is all correct except that the fold_non_dependent_init is
somewhat questionable to me; do we really have to fold in order to say
if the NSDMI init can throw?  Sure, we need to digest the {}, maybe
the field's ctors can throw, but I don't know about the folding.

> But it's certainly true that the "function_body" test is wrong in this
> situation; you might move the c_f_d test into the calculation of that
> variable.  The patch is OK with that change, but please also answer my
> question above.

I like that.  Before I go ahead and apply, please let me know if the answer
above is satisfying.

-- >8 --
Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
while processing the default argument in this test.  At this point
start_preparsed_function hasn't yet set current_function_decl.
expand_vec_init_expr then leads to maybe_splice_retval_cleanup which
checks DECL_CONSTRUCTOR_P (current_function_decl) without checking that
c_f_d is non-null first.  It seems correct that c_f_d is null here, so
it seems to me that maybe_splice_retval_cleanup should check c_f_d as
in the following patch.

	PR c++/106925


	* (maybe_splice_retval_cleanup): Check current_function_decl.
	Make the bool const.


	* g++.dg/cpp0x/initlist-defarg3.C: New test.
 gcc/cp/                              |  7 +++++--
 gcc/testsuite/g++.dg/cpp0x/initlist-defarg3.C | 13 +++++++++++++
 2 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-defarg3.C

diff --git a/gcc/cp/ b/gcc/cp/
index b8a85ed0572..a9114a5f7a5 100644
--- a/gcc/cp/
+++ b/gcc/cp/
@@ -1322,9 +1322,12 @@ maybe_splice_retval_cleanup (tree compound_stmt)
   /* If we need a cleanup for the return value, add it in at the same level as
      pushdecl_outermost_localscope.  And also in try blocks.  */
-  bool function_body
+  const bool function_body
     = (current_binding_level->level_chain
-       && current_binding_level->level_chain->kind == sk_function_parms);
+       && current_binding_level->level_chain->kind == sk_function_parms
+      /* When we're processing a default argument, c_f_d may not have been
+	 set.  */
+       && current_function_decl);
   if ((function_body || current_binding_level->kind == sk_try)
       && !DECL_CONSTRUCTOR_P (current_function_decl)
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-defarg3.C b/gcc/testsuite/g++.dg/cpp0x/initlist-defarg3.C
new file mode 100644
index 00000000000..5c3e886b306
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-defarg3.C
@@ -0,0 +1,13 @@
+// PR c++/106925
+// { dg-do compile { target c++11 } }
+struct Foo;
+template <int _Nm> struct __array_traits { typedef Foo _Type[_Nm]; };
+template <int _Nm> struct array {
+  typename __array_traits<_Nm>::_Type _M_elems;
+template <int size> struct MyVector { array<size> data{}; };
+struct Foo {
+  float a{0};
+void foo(MyVector<1> = MyVector<1>());

base-commit: fbf423309e103b54f7c9d39b2f7870b9bedfe9d2

  reply	other threads:[~2022-10-12 16:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11 20:00 [PATCH] " Marek Polacek
2022-10-11 20:28 ` Jason Merrill
2022-10-12 16:27   ` Marek Polacek [this message]
2022-10-12 16:47     ` [PATCH v2] " Jason Merrill
2022-10-12 17:12       ` Marek Polacek
2022-10-12 18:23         ` Marek Polacek
2022-10-13 13:58           ` Marek Polacek
2022-10-13 14:45             ` Jason Merrill
2022-10-13 14:44           ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).