public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] coroutines: Use cp_build_init_expr consistently.
Date: Tue, 11 Oct 2022 19:19:02 -0400	[thread overview]
Message-ID: <ace212c3-2e73-1c13-6fa8-48fad44ec787@redhat.com> (raw)
In-Reply-To: <9403FB3B-D300-4F62-B5D8-8BA83BB66F42@sandoe.co.uk>

On 10/11/22 18:17, Iain Sandoe wrote:
> Hi Jason
> 
>> On 11 Oct 2022, at 23:06, Jason Merrill <jason@redhat.com> wrote:
>>
>> On 10/11/22 17:58, Iain Sandoe wrote:
>>> Tested on x86_64-darwin19, OK for master?
>>> thanks
>>> Iain
>>> -- >8 --
>>> Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
>>> is set properly on target exprs.  The code here has a mixture of APIs used
>>> to build inits.  This patch changes that to use cp_build_init_expr() where
>>> possible, since that handles setting the flag.
>>
>> Hmm, I wouldn't expect this to be necessary, since cp_build_modify_expr calls cp_build_init_expr for INIT_EXPR.
> 
> It seems that path is only taken if the init is a CONSTRUCTOR.

If it's not a CONSTRUCTOR it builds a constructor call, which should end 
up having the same effect.  Certainly cp_build_init_expr is simpler if 
it works, so the patch is OK, but if it's necessary that indicates a bug 
that should be fixed.

>>   Perhaps the similarity of the function names is a trap...
> 
> not sure exactly what trap you mean.

The names are close, but cp_build_modify_expr is a lot more complicated; 
it handles conversions and overloaded operators.

> It seems that on my local set of additional tests (for some of the open prs) there are some
> progressions from this change, I will have to track down which change is the cause.
> 
> thanks
> Iain
> 
>>
>>> ---
>>>   gcc/cp/coroutines.cc | 25 ++++++++-----------------
>>>   1 file changed, 8 insertions(+), 17 deletions(-)
>>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>>> index 01a3e831ee5..20d309445eb 100644
>>> --- a/gcc/cp/coroutines.cc
>>> +++ b/gcc/cp/coroutines.cc
>>> @@ -1025,8 +1025,7 @@ build_co_await (location_t loc, tree a, suspend_point_kind suspend_kind)
>>>     else
>>>       {
>>>         e_proxy = get_awaitable_var (suspend_kind, o_type);
>>> -      o = cp_build_modify_expr (loc, e_proxy, INIT_EXPR, o,
>>> -				tf_warning_or_error);
>>> +      o = cp_build_init_expr (loc, e_proxy, o);
>>>       }
>>>       /* I suppose we could check that this is contextually convertible to bool.  */
>>> @@ -2889,8 +2888,7 @@ flatten_await_stmt (var_nest_node *n, hash_set<tree> *promoted,
>>>   	  gcc_checking_assert (!already_present);
>>>   	  tree inner = TREE_OPERAND (init, 1);
>>>   	  gcc_checking_assert (TREE_CODE (inner) != COND_EXPR);
>>> -	  init = cp_build_modify_expr (input_location, var, INIT_EXPR, init,
>>> -				       tf_warning_or_error);
>>> +	  init = cp_build_init_expr (var, init);
>>>   	  /* Simplify for the case that we have an init containing the temp
>>>   	     alone.  */
>>>   	  if (t == n->init && n->var == NULL_TREE)
>>> @@ -3656,8 +3654,7 @@ await_statement_walker (tree *stmt, int *do_subtree, void *d)
>>>   	    if (TREE_CODE (cond_inner) == CLEANUP_POINT_EXPR)
>>>   	      cond_inner = TREE_OPERAND (cond_inner, 0);
>>>   	    location_t sloc = EXPR_LOCATION (SWITCH_STMT_COND (sw_stmt));
>>> -	    tree new_s = cp_build_init_expr (sloc, newvar,
>>> -				     cond_inner);
>>> +	    tree new_s = cp_build_init_expr (sloc, newvar, cond_inner);
>>>   	    finish_expr_stmt (new_s);
>>>   	    SWITCH_STMT_COND (sw_stmt) = newvar;
>>>   	    /* Now add the switch statement with the condition re-
>>> @@ -4902,9 +4899,8 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer)
>>>   	      if (flag_exceptions)
>>>   		{
>>>   		  /* This var is now live.  */
>>> -		  r = build_modify_expr (fn_start, parm.guard_var,
>>> -					 boolean_type_node, INIT_EXPR, fn_start,
>>> -					 boolean_true_node, boolean_type_node);
>>> +		  r = cp_build_init_expr (fn_start, parm.guard_var,
>>> +					  boolean_true_node);
>>>   		  finish_expr_stmt (r);
>>>   		}
>>>   	    }
>>> @@ -4948,9 +4944,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer)
>>>         r = coro_build_cvt_void_expr_stmt (r, fn_start);
>>>         finish_expr_stmt (r);
>>>   -      r = build_modify_expr (fn_start, coro_promise_live, boolean_type_node,
>>> -			     INIT_EXPR, fn_start, boolean_true_node,
>>> -			     boolean_type_node);
>>> +      r = cp_build_init_expr (fn_start, coro_promise_live, boolean_true_node);
>>>         finish_expr_stmt (r);
>>>           promise_dtor
>>> @@ -5031,8 +5025,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer)
>>>   				       NULL_TREE);
>>>         add_decl_expr (gro);
>>>         gro_bind_vars = gro;
>>> -      r = cp_build_modify_expr (input_location, gro, INIT_EXPR, get_ro,
>>> -				tf_warning_or_error);
>>> +      r = cp_build_init_expr (gro, get_ro);
>>>         /* The constructed object might require a cleanup.  */
>>>         if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (gro_type))
>>>   	{
>>> @@ -5053,9 +5046,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer)
>>>        cleanup.  */
>>>     if (gro_ret_dtor)
>>>       {
>>> -       r = build_modify_expr (fn_start, coro_gro_live, boolean_type_node,
>>> -			      INIT_EXPR, fn_start, boolean_true_node,
>>> -			      boolean_type_node);
>>> +       r = cp_build_init_expr (fn_start, coro_gro_live, boolean_true_node);
>>>         finish_expr_stmt (r);
>>>       }
>>>     /* Initialize the resume_idx_var to 0, meaning "not started".  */
>>
> 


  reply	other threads:[~2022-10-11 23:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11 21:58 Iain Sandoe
2022-10-11 22:06 ` Jason Merrill
2022-10-11 22:17   ` Iain Sandoe
2022-10-11 23:19     ` Jason Merrill [this message]
2022-10-12  6:34       ` Iain Sandoe

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=ace212c3-2e73-1c13-6fa8-48fad44ec787@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).