public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathaniel Shead <nathanieloshead@gmail.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Patrick Palka <ppalka@redhat.com>
Subject: Re: [PATCH v3 1/3] c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]
Date: Sun, 16 Jul 2023 23:47:21 +1000	[thread overview]
Message-ID: <ZLP06W4SMTBu0rbB@Thaum.localdomain> (raw)
In-Reply-To: <1abfe7ac-1d9e-da4c-3f09-9e446b7ca3ff@redhat.com>

On Fri, Jul 14, 2023 at 11:16:58AM -0400, Jason Merrill wrote:
> On 6/30/23 23:28, Nathaniel Shead via Gcc-patches wrote:
> > This adds rudimentary lifetime tracking in C++ constexpr contexts,
> 
> Thanks!
> 
> I'm not seeing either a copyright assignment or DCO certification for you;
> please see https://gcc.gnu.org/contribute.html#legal for more information.
> 
> > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > index cca0435bafc..bc59b4aab67 100644
> > --- a/gcc/cp/constexpr.cc
> > +++ b/gcc/cp/constexpr.cc
> > @@ -1188,7 +1190,12 @@ public:
> >       if (!already_in_map && modifiable)
> >         modifiable->add (t);
> >     }
> > -  void remove_value (tree t) { values.remove (t); }
> > +  void remove_value (tree t)
> > +  {
> > +    if (DECL_P (t))
> > +      outside_lifetime.add (t);
> > +    values.remove (t);
> 
> What if, instead of removing the variable from one hash table and adding it
> to another, we change the value to, say, void_node?

I have another patch I'm working on after this which does seem to
require the overlapping tables to properly catch uses of aggregates
while they are still being constructed (i.e. before their lifetime has
begun), as part of PR c++/109518. In that case the 'values' map contains
the CONSTRUCTOR node for the aggregate, but it also needs to be in
'outside_lifetime'. I could also explore solving this another way
however if you prefer.

(I also have vague dreams of at some point making this a map to the
location that the object was destroyed for more context in the error
messages, but I'm not yet sure if that's feasible or will actually be
all that helpful so I'm happy to forgo that.)

> > +	  /* Also don't cache a call if we return a pointer to an expired
> > +	     value.  */
> > +	  if (cacheable && (cp_walk_tree_without_duplicates
> > +			    (&result, find_expired_values,
> > +			     &ctx->global->outside_lifetime)))
> > +	    cacheable = false;
> 
> I think we need to reconsider cacheability in general; I think we only want
> to cache calls that are themselves valid constant expressions, in that the
> return value is a "permitted result of a constant expression"
> (https://eel.is/c++draft/expr.const#13).  A pointer to an automatic variable
> is not, whether or not it is currently within its lifetime.
> 
> That is, only cacheable if reduced_constant_expression_p (result).
> 
> I'm experimenting with this now, you don't need to mess with it.

Thanks! I agree, that sounds a lot nicer; I definitely ran into caching
problems in a few different ways when I was developing this patch, and
this approach sounds like it would have avoided that.

> > @@ -7085,7 +7138,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t,
> >       case PARM_DECL:
> >         if (lval && !TYPE_REF_P (TREE_TYPE (t)))
> >   	/* glvalue use.  */;
> > -      else if (tree v = ctx->global->get_value (r))
> > +      else if (tree v = ctx->global->get_value (t))
> 
> I agree with this change, but it doesn't have any actual effect, right? I'll
> go ahead and apply it separately.

Yup, it was just a drive-by cleanup I made while trying to understand
this part of the code. Thanks.

> > @@ -7328,17 +7386,28 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t,
> >   	auto_vec<tree, 2> cleanups;
> >   	vec<tree> *prev_cleanups = ctx->global->cleanups;
> >   	ctx->global->cleanups = &cleanups;
> > -	r = cxx_eval_constant_expression (ctx, TREE_OPERAND (t, 0),
> > +
> > +	auto_vec<tree, 10> save_exprs;
> 
> Now that we're going to track temporaries for each full-expression, I think
> we shouldn't also need to track them for loops and calls.

Good point, I didn't think about that. I'm now bootstrapping/regtesting
a modification of this patch that removes the tracking in loops and
calls, but an initial run of the dg.exp testsuite is promising. It also
fixes an issue I just noticed where I don't actually check lifetimes of
empty types.

I'll send out a new version when that finishes.

  parent reply	other threads:[~2023-07-16 13:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-01  3:24 [PATCH v3 0/3] c++: Track lifetimes in constant evaluation [PR70331,...] Nathaniel Shead
2023-07-01  3:28 ` [PATCH v3 1/3] c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675] Nathaniel Shead
2023-07-14 15:16   ` Jason Merrill
2023-07-14 22:40     ` Jason Merrill
2023-07-16 13:47     ` Nathaniel Shead [this message]
2023-07-17 16:04       ` Jason Merrill
2023-07-01  3:30 ` [PATCH v3 2/3] c++: Improve constexpr error for dangling local variables Nathaniel Shead
2023-07-01  3:30 ` [PATCH v3 3/3] c++: Improve location information in constant evaluation Nathaniel Shead
2023-07-10 19:23 ` [PATCH v3 0/3] c++: Track lifetimes in constant evaluation [PR70331,...] Patrick Palka

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=ZLP06W4SMTBu0rbB@Thaum.localdomain \
    --to=nathanieloshead@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=ppalka@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).