Message ID | 20220930220623.2161990-1-jason@redhat.com |
---|---|
State | Accepted, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp8537wrs; Fri, 30 Sep 2022 15:08:43 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4y8TG2INzMKFLy3NHWxV7WpQH+ED82/KkEeloZ+uqYeIP4wUJPQK1YYg8gyrWVQ+onLAfK X-Received: by 2002:a05:6402:1a42:b0:458:b430:7e70 with SMTP id bf2-20020a0564021a4200b00458b4307e70mr238456edb.293.1664575722988; Fri, 30 Sep 2022 15:08:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664575722; cv=none; d=google.com; s=arc-20160816; b=b8WnVeaXZNThUVGa7kSQTlLTqF/FZbC0HWIUSGMrqQU0OjGRg2gRO9bVpemrC9JVtR s5cql9ts6/Bdbk+3oH0STFbEvO0WbTQ3gg2uD8AF3qTRW6OhGOw8ejk01AsjcAKE+Gf6 3nroxzgRU589hf+CKJtjWZLokwtRnmb84oQWlT0T79gcc4h+dX0CQRzC7fzdRNdV1yYJ bTSgzDaJ1BFecqdf+AKGF0fPvUN/UnNVphWZqnQNTLxnLiUs638+RgAfhoICJ8qT8D1X oreqIrsF8pI2kb6FvFzyou2e67gok4+sSgtTyGcsYLdqu8FwYCsP5zFMPA8LP1nhrwJN LmbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:to :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=SAYU/3Oxah2WcKqRl924OPQ1aSSePyjYD37XuaWVgIA=; b=COV0NQaw+5WY2Pf/OX9/c1b8J4h82QgrL0ta9MwC3JC6UMqRC+dleeQhLwfPn5ws9n UW5gvhlkjiJHixyNApHiS8+/7v5/tjG0rHmKzR0EUmnEp5nyaujHw3TXvLO6sGbURGOi RrVRDyUn6n1S6muwhyfpBX6pdJjycjI4bGB/34mYeY2RH2RIswu8Hso29g/OGRimYZAO L4UXJS5uHfFSZfjXOy1zHcFyJV2FCJr/Qfq1R8BqSVDrMGnNN8y8qck+TZmzhiF0CKxp xtfEqz11Y6HgRTVQ5CGjYGAi0KKSTeCLuZA1k50lvJENFhyneGjZ68yxyp+uZeO6mOMo FCTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=CssE2Dg+; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id k30-20020a50ce5e000000b00456c837e3d0si2396041edj.77.2022.09.30.15.08.42 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 15:08:42 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=CssE2Dg+; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B432C385701C for <ouuuleilei@gmail.com>; Fri, 30 Sep 2022 22:08:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B432C385701C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664575721; bh=SAYU/3Oxah2WcKqRl924OPQ1aSSePyjYD37XuaWVgIA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=CssE2Dg+s/m4G6FCyKNehR95cG02jCR1IwmQDgEKCI+zpBcKuf99KwtEy+GimHJa9 W41ecIIQbmTJEvsuMzL2H3IZJ3kpRAq8YKJ0KB+TW2k9tqYwonqry/VR1ZAqOOnK/7 mCtqmGm4/J8vSgTxbMrt11akOIsPqmPu0Kqao3Tg= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5FB6C3858D1E for <gcc-patches@gcc.gnu.org>; Fri, 30 Sep 2022 22:06:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5FB6C3858D1E Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-64-aJbdrSWoN5WenVtPsjrtlw-1; Fri, 30 Sep 2022 18:06:27 -0400 X-MC-Unique: aJbdrSWoN5WenVtPsjrtlw-1 Received: by mail-qt1-f197.google.com with SMTP id bn4-20020a05622a1dc400b0035d24923a7fso3824191qtb.0 for <gcc-patches@gcc.gnu.org>; Fri, 30 Sep 2022 15:06:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date; bh=SAYU/3Oxah2WcKqRl924OPQ1aSSePyjYD37XuaWVgIA=; b=ejL9WBYWts6SCtGBVeVh3rG95IwY9GBZ1NDlkXJuBNBjgGPZ5YhcqtdNk+8t/95MU+ yI90h7hUSp3LlGmRGenp7xsGYWWg3TmfhyiQNauFYWMrnBNzjbvXlTb7opnxrTIrNzwV Er3N6elUwAMzKs+WV31cu0X4BnjAPqn2ZJFVb5qtU/O9wkneuXRtoPKC47rkPSXF37lQ +iGXUqvwSCJqcy9vO429g546QJd7p24oX1lxcvILdRR5Fq9DMnS8/A8qSzsBhX3lf7bd E3dNWsdl+AXTfEkh8LnXItPCntI6AXwPlfs9Bgytlov/3IYLK6/PAX8g5tmnIkNGt+bs cQ5g== X-Gm-Message-State: ACrzQf2wHm1uM4UO8h3253zVrwaUNqh1cQXZKgdEOeWrZRIGVZEfi0Ge vtBYg0CRMs11g4z9z5I1fgZcuXeNh6bMgE5yabNZDJBov5/kM9dmkjOX6plo2QvYWBXZLT54e3A SfIJFAEa4vEKTyrOsWPdophFFWsVx/aOBqejnd4woGgpOQBjYgRR/35yg/OI5+XotFQ== X-Received: by 2002:a05:6214:b27:b0:4a5:e6df:2007 with SMTP id w7-20020a0562140b2700b004a5e6df2007mr8651848qvj.96.1664575587184; Fri, 30 Sep 2022 15:06:27 -0700 (PDT) X-Received: by 2002:a05:6214:b27:b0:4a5:e6df:2007 with SMTP id w7-20020a0562140b2700b004a5e6df2007mr8651813qvj.96.1664575586710; Fri, 30 Sep 2022 15:06:26 -0700 (PDT) Received: from barrymore.redhat.com (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id s17-20020a05620a29d100b006cbc00db595sm3726503qkp.23.2022.09.30.15.06.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 15:06:25 -0700 (PDT) To: gcc-patches@gcc.gnu.org, Iain Sandoe <iain@sandoe.co.uk> Subject: [PATCH RFC] c++: fix broken conversion in coroutines Date: Fri, 30 Sep 2022 18:06:23 -0400 Message-Id: <20220930220623.2161990-1-jason@redhat.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jason Merrill via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jason Merrill <jason@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1745434153018826664?= X-GMAIL-MSGID: =?utf-8?q?1745434153018826664?= |
Series |
[RFC] c++: fix broken conversion in coroutines
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Jason Merrill
Sept. 30, 2022, 10:06 p.m. UTC
You can't use CONVERT_EXPR to convert between two class types, and it was breaking copy elision. Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where susp_type is Loopy<int>::handle_type. How is this supposed to work? gcc/cp/ChangeLog: * coroutines.cc (expand_one_await_expression): Change conversion to assert. --- gcc/cp/coroutines.cc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) base-commit: 43faf3e5445b571731e52faa1be085ecd0a09323
Comments
Hi Jason, > On 30 Sep 2022, at 23:06, Jason Merrill <jason@redhat.com> wrote: > > You can't use CONVERT_EXPR to convert between two class types, and it was > breaking copy elision. > > Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where > susp_type is Loopy<int>::handle_type. How is this supposed to work? We are trying to save a type-erased handle (which the symmetric transfer makes and indirect call through, nothing else). so, I suppose the equivalent could be: conthand = coroutine_handle::from_address (suspend.address()) or, is there some cast version that would be valid here? Iain > > gcc/cp/ChangeLog: > > * coroutines.cc (expand_one_await_expression): Change conversion > to assert. > --- > gcc/cp/coroutines.cc | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc > index eca01abcb7a..568f2edf67d 100644 > --- a/gcc/cp/coroutines.cc > +++ b/gcc/cp/coroutines.cc > @@ -1728,7 +1728,9 @@ expand_one_await_expression (tree *stmt, tree *await_expr, void *d) > } > else > { > - r = build1_loc (loc, CONVERT_EXPR, void_coro_handle_type, suspend); > + gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p > + (void_coro_handle_type, susp_type)); > + r = suspend; > r = build2_loc (loc, INIT_EXPR, void_coro_handle_type, data->conthand, r); > r = build1 (CONVERT_EXPR, void_type_node, r); > append_to_statement_list (r, &body_list); > > base-commit: 43faf3e5445b571731e52faa1be085ecd0a09323 > -- > 2.31.1 >
On 9/30/22 18:50, Iain Sandoe wrote: > Hi Jason, > >> On 30 Sep 2022, at 23:06, Jason Merrill <jason@redhat.com> wrote: >> >> You can't use CONVERT_EXPR to convert between two class types, and it was >> breaking copy elision. >> >> Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where >> susp_type is Loopy<int>::handle_type. How is this supposed to work? > > We are trying to save a type-erased handle (which the symmetric transfer makes > and indirect call through, nothing else). The problem is you're treating one class directly as another class here, without the indirection involved in usual type-erasure idioms. It does seem that the gimplifier handles this fine, but it doesn't correspond to anything in the language and much of the front end assumes that CONVERT_EXPR is only used for scalars. VIEW_CONVERT_EXPR would better express that we're not doing anything to the value, just cheating the type system. That's still dodgy from a language perspective, but probably safe enough in this case. Note that I was wrong to mention copy elision above; it's irrelevant to codegen here since the handle type returns in a register. > so, I suppose the equivalent could be: > > conthand = coroutine_handle::from_address (suspend.address()) That sounds more correct, yes. Jason
On 10/3/22 23:53, Jason Merrill wrote: > On 9/30/22 18:50, Iain Sandoe wrote: >> Hi Jason, >> >>> On 30 Sep 2022, at 23:06, Jason Merrill <jason@redhat.com> wrote: >>> >>> You can't use CONVERT_EXPR to convert between two class types, and it >>> was >>> breaking copy elision. >>> >>> Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where >>> susp_type is Loopy<int>::handle_type. How is this supposed to work? >> >> We are trying to save a type-erased handle (which the symmetric >> transfer makes >> and indirect call through, nothing else). > > The problem is you're treating one class directly as another class here, > without the indirection involved in usual type-erasure idioms. > > It does seem that the gimplifier handles this fine, but it doesn't > correspond to anything in the language and much of the front end assumes > that CONVERT_EXPR is only used for scalars. VIEW_CONVERT_EXPR would > better express that we're not doing anything to the value, just cheating > the type system. That's still dodgy from a language perspective, but > probably safe enough in this case. So I'm applying this:
> On 6 Oct 2022, at 22:44, Jason Merrill <jason@redhat.com> wrote: > > On 10/3/22 23:53, Jason Merrill wrote: >> On 9/30/22 18:50, Iain Sandoe wrote: >>> Hi Jason, >>> >>>> On 30 Sep 2022, at 23:06, Jason Merrill <jason@redhat.com> wrote: >>>> >>>> You can't use CONVERT_EXPR to convert between two class types, and it was >>>> breaking copy elision. >>>> >>>> Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where >>>> susp_type is Loopy<int>::handle_type. How is this supposed to work? >>> >>> We are trying to save a type-erased handle (which the symmetric transfer makes >>> and indirect call through, nothing else). >> The problem is you're treating one class directly as another class here, without the indirection involved in usual type-erasure idioms. >> It does seem that the gimplifier handles this fine, but it doesn't correspond to anything in the language and much of the front end assumes that CONVERT_EXPR is only used for scalars. VIEW_CONVERT_EXPR would better express that we're not doing anything to the value, just cheating the type system. That's still dodgy from a language perspective, but probably safe enough in this case. > > So I'm applying this:<0001-c-fix-broken-conversion-in-coroutines.patch> thanks, I have not had any cycles to look at this. however, when I next do - was planning on looking at the: cont = handle.from_address(await_suspend().address()) approach, since both .address() and .from_address() are constexpr, cp_fold_function should turn that into essentially a NOP. Iain
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc index eca01abcb7a..568f2edf67d 100644 --- a/gcc/cp/coroutines.cc +++ b/gcc/cp/coroutines.cc @@ -1728,7 +1728,9 @@ expand_one_await_expression (tree *stmt, tree *await_expr, void *d) } else { - r = build1_loc (loc, CONVERT_EXPR, void_coro_handle_type, suspend); + gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p + (void_coro_handle_type, susp_type)); + r = suspend; r = build2_loc (loc, INIT_EXPR, void_coro_handle_type, data->conthand, r); r = build1 (CONVERT_EXPR, void_type_node, r); append_to_statement_list (r, &body_list);