From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id C2B6D3858C33 for ; Tue, 9 May 2023 18:35:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C2B6D3858C33 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pwSAy-0005rR-Sn for gcc-patches@gcc.gnu.org; Tue, 09 May 2023 20:35:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE Date: Tue, 9 May 2023 20:35:00 +0200 Message-ID: <32e20f0e-cf48-f71d-2f2b-cd24d0d0eefd@gmx.de> References: <9b573e6c-52e0-ce7c-6ae4-9b21a55525e9@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote: > On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote: >> Hi Paul, >> >> On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote: >>> Hi All, >>> >>> Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because >>> this testcase checked that finalizable derived types could not be specified >>> in a submodule. I have replaced the original test with a test of the patch. >>> >>> Thanks also to Malcolm Cohen for guidance on this. >>> >>> OK for trunk? >> >> the patch looks good to me. However: >> >> @@ -11637,8 +11637,9 @@ gfc_match_final_decl (void) >> block = gfc_state_stack->previous->sym; > ^^^^^^^^^^^^^^^^^^^^^^^^^ > See below. > >> gcc_assert (block); >> >> - if (!gfc_state_stack->previous || !gfc_state_stack->previous->previous >> - || gfc_state_stack->previous->previous->state != COMP_MODULE) >> + if (gfc_state_stack->previous->previous >> + && gfc_state_stack->previous->previous->state != COMP_MODULE >> + && gfc_state_stack->previous->previous->state != COMP_SUBMODULE) >> { >> gfc_error ("Derived type declaration with FINAL at %C must be in >> the" >> " specification part of a MODULE"); >> >> I am wondering if we should keep the protection against a potential >> NULL pointer dereference (i.e. gfc_state_stack->previous == NULL) for >> possibly invalid code. I have failed to produce a simple testcase, >> but others may have "better" ideas. > > It's not needed. See above. gfc_state_stack->previous is referenced > a few lines above the if-stmt. The reference will segfault if the > pointer is NULL. > You're absolutely right. So it is OK as is. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by sourceware.org (Postfix) with ESMTPS id E63033858414; Tue, 9 May 2023 18:35:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E63033858414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1683657303; i=anlauf@gmx.de; bh=0MVwP3ME2aYXhXQaq5XvLqHUl8LE/krlRVZt1ZhQfTQ=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=mtKWrF6FqgoNDKFKv5YyLT7YNFGuR+zr4wfIdkAeP7HuUiv5+Oa/Ul9WS8FmfoLh8 s9Z1Xu40l8F2qqGdNVsUOCcsURaUEaAKWHiE8Jh93qq9O0JiRxXTHZ2bIlGw3NMYgD 1t5/7ynBxz9wVlXSpe5s30+kOYwy3I2MaPNLLPvZ8/GhQJrKO5adREaHcHGNZcaK4o 1e5KFzT2UfJ7byrhitOiPrE3na3RMZds77q8Ofc+/GN8SkW6fguGi4qcoMlIWNeF4V nQMRNPZZA5jKXPD2xNy9f9XgAAKupM72JnjSzixqKqvFo27ldZdbYBSVun8C+n8cVT aX2cURuwjx7uw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([93.207.91.40]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MDysg-1q6OLD38L6-00A0aR; Tue, 09 May 2023 20:35:03 +0200 Message-ID: <32e20f0e-cf48-f71d-2f2b-cd24d0d0eefd@gmx.de> Date: Tue, 9 May 2023 20:35:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE To: sgk@troutmask.apl.washington.edu Cc: Paul Richard Thomas , "fortran@gcc.gnu.org" , gcc-patches , "Steven G. Kargl" Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <9b573e6c-52e0-ce7c-6ae4-9b21a55525e9@gmx.de> Content-Language: en-US From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:IXUkUr76308C2MeHPR3hzX8zmc3xaNlaWsCbPyeLMZW3F41tbuE di31+I4zCnCcXi08bl1SvcEQSLhzi7rt2Up8bf7bv/LOTvC7DUDJkhYsYV51D2xo4mMM/XJ ERSkTqW1PtZyzMRCQWu3afqUFfK4+uQgQEDRAY2nrgIvrh5kwIyzLPnhU3SZ6J1mtocVpli 4jfrCGKcxzSyqdAe3vWGQ== UI-OutboundReport: notjunk:1;M01:P0:JavERf1dyqs=;33CuZFDAU4nEjf+luUbo95Fk99D p7R0BoOFvKeBDUKkrlZF72ciaus/DYbqC07lkJyQC5BjRl89G1sg6Okk0G+HzLodOV0l+XRqt x9+/hCt0ukFIWhi2n6BaFjRCV7ElXYIE6kPtuNBI8qE/D6Un+ebJMrwlG82+/YnpDx3Q5xeiF iPdMuEu4e2Y5dIVIBx3loBVWSlBoNsl2j1/OynlvKbrv7c68mes9oZpAnzIBFs0Z74dJb51js UHiO2liPqeqqs9drJwNDahA+DywxhThABP2TGZdlL/9ai1rbCFHdWmccnW+6kQeyR2ufTJ8+l VcFf/i+2Enijx+7BIlEhpMO9DXEJ4WisQMRRiinS/qKjHxK7PPk0/ZJdQ8UomjuG8GbUcBQK+ 0gx4lgqXMRMeLR6o4gcscSqqZTtyZG1YZLdC/uqjk50H4Iz1ajUWS1UNsjMjWcGmCRdBL5ZcU H1Op3DpOt3TcT7KPIoArodVvXcWxba63SjvotB+bgJv2tetNbpeqAgvn6RiLcCjURFFMEmwyu 3wgvhPPFUWr1SZdjkvqLYAMOJDa8SXtmgseVeo2H6SYdmBqhd6wWK7N6KyYS7E75lCSqtELbb bwnjTOSEC1+ZtOL3WXljPgped367Nqn1nkwK6jJsE3YaitWXJ0Kung3xw1HWHclu14E7Yfu3o GG+nFQCraVDF8/13Hf9PyIST+kkCE7md4FX9NXRvR1INfMJUFFoZdeZwS/gd9wnwjOQAXPZIq X3o1OmLjnUWN5ONoewnvmZfBi25IK5xuur65nPDsessrZ3mGtA3sjVcn4RatXHl8Wnp2bLyoE wK+svCbgkDEckYyNbmaF8qP9g7JPLqEv0lgMiKyDphQb2H8YM7Cpp7Tfu37xHdnk7VS2QWB1V gw+QEgrmzqwstUVx3P9czrc4ch7dzLPGQvKbMMvX1YE6Wsq9MN7DUkjq4MWCyvcZ3WX5fo82r AI9Czw== X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20230509183500.tnOE7QRXNQMQmGFC_MJ7JnGfbrfywcOHWbPdrlU7vTY@z> On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote: > On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote: >> Hi Paul, >> >> On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote: >>> Hi All, >>> >>> Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail be= cause >>> this testcase checked that finalizable derived types could not be spec= ified >>> in a submodule. I have replaced the original test with a test of the p= atch. >>> >>> Thanks also to Malcolm Cohen for guidance on this. >>> >>> OK for trunk? >> >> the patch looks good to me. However: >> >> @@ -11637,8 +11637,9 @@ gfc_match_final_decl (void) >> block =3D gfc_state_stack->previous->sym; > ^^^^^^^^^^^^^^^^^^^^^^^^^ > See below. > >> gcc_assert (block); >> >> - if (!gfc_state_stack->previous || !gfc_state_stack->previous->previo= us >> - || gfc_state_stack->previous->previous->state !=3D COMP_MODULE) >> + if (gfc_state_stack->previous->previous >> + && gfc_state_stack->previous->previous->state !=3D COMP_MODULE >> + && gfc_state_stack->previous->previous->state !=3D COMP_SUBMODUL= E) >> { >> gfc_error ("Derived type declaration with FINAL at %C must be i= n >> the" >> " specification part of a MODULE"); >> >> I am wondering if we should keep the protection against a potential >> NULL pointer dereference (i.e. gfc_state_stack->previous =3D=3D NULL) f= or >> possibly invalid code. I have failed to produce a simple testcase, >> but others may have "better" ideas. > > It's not needed. See above. gfc_state_stack->previous is referenced > a few lines above the if-stmt. The reference will segfault if the > pointer is NULL. > You're absolutely right. So it is OK as is.