From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 552E63858D28 for ; Sun, 27 Mar 2022 01:33:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 552E63858D28 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-303-XTJnOwkKPl2xmkYNuVAyxQ-1; Sat, 26 Mar 2022 21:33:29 -0400 X-MC-Unique: XTJnOwkKPl2xmkYNuVAyxQ-1 Received: by mail-qv1-f69.google.com with SMTP id g2-20020a0562141cc200b004123b0abe18so8810230qvd.2 for ; Sat, 26 Mar 2022 18:33:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:cc:from:in-reply-to :content-transfer-encoding; bh=9e/Y6mrObk6FYExWs/wd40txxFjtoFx9uuYUestnZBs=; b=r5ChxZMW6akML9Vzn3kHTLkI79wc7r+ZMkbJIjm75wC0t8WvAKv+C7+iEHPrREPkl7 Nv17ojAA26ZKDkJ/YxWaoZbqTXgXqJy/WmeQd8HcwDLM4ttHN7sbA9Yfh7rA2HYuYILF rVaZjT/oVT0tvcwrBk04uMoFriUPleEWoiDbx79VrO3lDqjrfjIQxmZw3jxWAKyjJkU9 QfBZZMBjw8RxiPr7IyDPb124UIFBLmpIAHp8KR4Yd+Nourar9oSfKoOi5DiQkht24+jF 7yAKtOTpHrfLfySn4b82kHVBI9tp1AYIldrV32tYD5TAJzHtv2JZjJZgKfPfzIQ6/b8t cnwA== X-Gm-Message-State: AOAM531Vuk0tsN8MqHVQbNbay/yN6RQSQ9WOYp0lK5xV/AaimtWHL+UV uRa0xudtwLJqOlca2TqLwMxGJmoasEHlU24S14iFz5CIvUdvnN6936lWsXnroLAkNja3eaNF4TA WL458VML2Yf7TAhPuqg== X-Received: by 2002:ac8:5e0c:0:b0:2d0:a808:908e with SMTP id h12-20020ac85e0c000000b002d0a808908emr15826430qtx.115.1648344809289; Sat, 26 Mar 2022 18:33:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwivoDPn4eorzy/6lUjce/x0N5uIRfiTX1XsxdzcLqaVuMRrW3m45RWpNTfzdGc+iwlHpO4Zg== X-Received: by 2002:ac8:5e0c:0:b0:2d0:a808:908e with SMTP id h12-20020ac85e0c000000b002d0a808908emr15826417qtx.115.1648344808985; Sat, 26 Mar 2022 18:33:28 -0700 (PDT) Received: from [192.168.1.149] (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 h14-20020a05622a170e00b002e1a65754d8sm9325087qtk.91.2022.03.26.18.33.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Mar 2022 18:33:28 -0700 (PDT) Message-ID: Date: Sat, 26 Mar 2022 21:33:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH RFC] Fix ICE due to shared BLOCK node in coroutine generation [PR103328] To: Benno Evers , gcc-patches@gcc.gnu.org References: Cc: iain Sandoe From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2022 01:33:37 -0000 On 3/17/22 07:37, Benno Evers via Gcc-patches wrote: > The coroutine transformation moves the original function body into a > newly created actor function, but the block of the > `current_binding_level` still points into the original function, > causing the block to be shared between the two functions if it is > subsequently used. This may cause havoc later on, as subsequent > compiler passes for one function will also implicitly modify the > other. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328#c19 for > a more detailed writeup. > > This patch fixes the issue locally, but I'm not familiar with the GCC > code base so I'm not sure if this is the right way to go about it or > if there's a cleaner way to reset the current binding level. If this > is the way to go I'm happy to extend the patch with a testcase and > changelog entry. Please do, it looks like a good fix to me. Iain, does it make sense to you as well? > --- > gcc/cp/coroutines.cc | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc > index b1bfdc767a4..eb5f80f499b 100644 > --- a/gcc/cp/coroutines.cc > +++ b/gcc/cp/coroutines.cc > @@ -4541,6 +4541,8 @@ morph_fn_to_coro (tree orig, tree *resumer, tree > *destroyer) > BLOCK_VARS (top_block) = BIND_EXPR_VARS (ramp_bind); > BLOCK_SUBBLOCKS (top_block) = NULL_TREE; > > + current_binding_level->blocks = top_block; > + > /* The decl_expr for the coro frame pointer, initialize to zero so that we > can pass it to the IFN_CO_FRAME (since there's no way to pass a type, > directly apparently). This avoids a "used uninitialized" warning. */