public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: iain@sandoe.co.uk, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++,coroutines: Stabilize names of promoted slot vars [PR101118].
Date: Wed, 29 Mar 2023 15:23:33 -0400	[thread overview]
Message-ID: <5ebaf601-dca1-292b-de37-b748ab3f6e51@redhat.com> (raw)
In-Reply-To: <20230326165447.43628-1-iain@sandoe.co.uk>

On 3/26/23 12:54, Iain Sandoe wrote:
> Tested on x86_64-darwin21, x86-64-linux-gnu
> OK for trunk?
> Iain
> 
> When we need to 'promote' a value (i.e. store it in the coroutine frame) it
> is given a frame entry name.  This was based on the DECL_UID for slot vars.
> However, when LTO is used, the names from multiple TUs become visible at the
> same time, and the DECL_UIDs usually differ between units.  This leads to a
> "ODR mismatch" warning for the frame type.
> 
> The fix here is to use a counter instead of the DECL_UID which makes a name
> that is stable between TUs for each frame layout (one per coroutine func).
> 
> Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
> 
> 	PR c++/101118
> 
> gcc/cp/ChangeLog:
> 
> 	* coroutines.cc: Add counter for promoted slot vars.
> 	(flatten_await_stmt): Use slot vars counter instead of DECL_UID
> 	to generate the frame entry name for promoted target expression
> 	slot variables.
> 	(morph_fn_to_coro): Reset the slot vars counter at the start of
> 	each coroutine function.
> ---
>   gcc/cp/coroutines.cc | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index a2189e43db8..359a5bf46ff 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -2726,6 +2726,11 @@ struct var_nest_node
>     var_nest_node *else_cl;
>   };
>   
> +/* This is used to make a stable, but unique-per-function, sequence number for
> +   each TARGET_EXPR slot variable that we 'promote' to a frame entry.  It needs
> +   to be stable because the frame type is visible to LTO ODR checking.  */
> +static unsigned tmpno = 0;

How about using temps_used->elements() for the index instead of a 
separate static counter?

>   /* This is called for single statements from the co-await statement walker.
>      It checks to see if the statement contains any initializers for awaitables
>      and if any of these capture items by reference.  */
> @@ -2889,7 +2894,7 @@ flatten_await_stmt (var_nest_node *n, hash_set<tree> *promoted,
>   	  tree init = t;
>   	  temps_used->add (init);
>   	  tree var_type = TREE_TYPE (init);
> -	  char *buf = xasprintf ("D.%d", DECL_UID (TREE_OPERAND (init, 0)));
> +	  char *buf = xasprintf ("T%03u", tmpno++);
>   	  tree var = build_lang_decl (VAR_DECL, get_identifier (buf), var_type);
>   	  DECL_ARTIFICIAL (var) = true;
>   	  free (buf);
> @@ -4374,6 +4379,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer)
>   {
>     gcc_checking_assert (orig && TREE_CODE (orig) == FUNCTION_DECL);
>   
> +  tmpno = 0;
>     *resumer = error_mark_node;
>     *destroyer = error_mark_node;
>     if (!coro_function_valid_p (orig))


  parent reply	other threads:[~2023-03-29 19:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-26 16:54 Iain Sandoe
2023-03-27  6:40 ` [PATCH] c++, coroutines: " Richard Biener
2023-03-27  6:58   ` Iain Sandoe
2023-03-27  7:18     ` Richard Biener
2023-03-27  7:32       ` Iain Sandoe
2023-03-28  6:28         ` Richard Biener
2023-03-28  6:57           ` Iain Sandoe
2023-03-28 11:16             ` Iain Sandoe
2023-03-28 11:27               ` Richard Biener
2023-03-29 19:23 ` Jason Merrill [this message]
2023-03-30  7:53   ` [PATCH] c++,coroutines: " Iain Sandoe
2023-03-30 20:50     ` 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=5ebaf601-dca1-292b-de37-b748ab3f6e51@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    /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).