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". */
>>
>
next prev parent 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).