public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Patrick Palka <ppalka@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [pushed] c++: constant, array, lambda, template [PR108975]
Date: Sat, 18 Mar 2023 09:50:54 -0400 (EDT)	[thread overview]
Message-ID: <162739c5-32da-bc17-bae5-47df5d89be59@idea> (raw)
In-Reply-To: <20230317233249.1406928-1-jason@redhat.com>

On Fri, 17 Mar 2023, Jason Merrill via Gcc-patches wrote:

> Tested x86_64-pc-linux-gnu, applying to trunk.
> 
> -- 8< --
> 
> When a lambda refers to a constant local variable in the enclosing scope, we
> tentatively capture it, but if we end up pulling out its constant value, we
> go back at the end of the lambda and prune any unneeded captures.  Here
> while parsing the template we decided that the dim capture was unneeded,
> because we folded it away, but then we brought back the use in the template
> trees that try to preserve the source representation with added type info.
> So then when we tried to instantiate that use, we couldn't find what it was
> trying to use, and crashed.
> 
> Fixed by not trying to prune when parsing a template; we'll prune at
> instantiation time.
> 
> 	PR c++/108975
> 
> gcc/cp/ChangeLog:
> 
> 	* lambda.cc (prune_lambda_captures): Don't bother in a template.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/cpp0x/lambda/lambda-const11.C: New test.
> ---
>  gcc/cp/lambda.cc                                   |  3 +++
>  gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const11.C | 14 ++++++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const11.C
> 
> diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
> index 212990a21bf..9925209b2ed 100644
> --- a/gcc/cp/lambda.cc
> +++ b/gcc/cp/lambda.cc
> @@ -1760,6 +1760,9 @@ prune_lambda_captures (tree body)
>    if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lam) == CPLD_NONE)
>      /* No default captures, and we don't prune explicit captures.  */
>      return;
> +  /* Don't bother pruning in a template, we'll prune at instantiation time.  */
> +  if (dependent_type_p (TREE_TYPE (lam)))
> +    return;
>  
>    hash_map<tree,tree*> const_vars;
>  
> diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const11.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const11.C
> new file mode 100644
> index 00000000000..26af75bf132
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const11.C
> @@ -0,0 +1,14 @@
> +// PR c++/108975
> +// { dg-do compile { target c++11 } }
> +
> +template<class T>
> +void f() {
> +  constexpr int dim = 1;
> +  auto l = [&] {
> +    int n[dim * 1];
> +  };
> +  // In f<int>, we shouldn't actually capture dim.
> +  static_assert (sizeof(l) == 1, "");
> +}
> +
> +template void f<int>();

Sadly I think more is needed to fix the generic lambda case, we still
crash for:

  template<class T>
  void f() {
    constexpr int dim = 1;
    auto l = [&] (auto) {
      int n[dim * 1];
    };
    l(0);
    // In f<int>, we shouldn't actually capture dim.
    static_assert (sizeof(l) == 1, "");
  }

  template void f<int>();

It seems prune_lambda_captures doesn't thoroughly walk the lambda body,
and so fails to find all uses of constant captures such as in 'int n[dim * 1]'
or 'using type = decltype(g<dim * 1>())' (in the original testcase the
constant capture use occurred inside an alias declaration).

I guess generic lambdas are special in that their body is always
templated and so fewer constant captures are folded away by instantiation
time.  So they are more sensitive to incomplete walking by
prune_lambda_captures.


  reply	other threads:[~2023-03-18 13:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 23:32 Jason Merrill
2023-03-18 13:50 ` Patrick Palka [this message]
2023-04-25 14:55   ` Patrick Palka
2023-04-25 19:25     ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=162739c5-32da-bc17-bae5-47df5d89be59@idea \
    --to=ppalka@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).