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 251283858419; Tue, 28 Dec 2021 21:08:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 251283858419 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gluon.fritz.box ([79.251.11.226]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mz9Un-1mF9K21MId-00wI0I; Tue, 28 Dec 2021 22:08:05 +0100 Subject: Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366 To: Paul Richard Thomas Cc: gcc-patches , fortran Newsgroups: gmane.comp.gcc.fortran,gmane.comp.gcc.patches References: From: Harald Anlauf Message-ID: <5187e5f9-fc22-be34-a671-0268f718a78b@gmx.de> Date: Tue, 28 Dec 2021 22:08:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:RNBGN/9e8VDfSJJJj7bPGxWLdsFI1O29/yZ0OJFz1hUWxrpVUGs cQhPHhu8GxT7q3Zdo1Cf3BQv9CYMI1TOim80lFiRFuoYhi7ZUZf97V2ZDgmYK2zXd1FIERW yI+s3z2tHV/OeuAwkD/dhwW7HanG5yGK7wTzmlyQfwNBJRyoZkZNzelIov3TEkJJLPknYw5 48O8RKu3KmkiE9Is9l+SQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:i6Umm6lhDf4=:M58OzD8Vm3njb8q4u4DQVN KiBLyLqOdloeFlyQuFVygnYhrqmFt6JZV77KQXLlpPMmP2ELfayYydf4Jx+bhTzWQSLe1QDaf 3H5yVQq+uPPHNJVV+NVYS7C8NlQFsx4qK2VvL3UtJKI9Wf87CC4okld63oP7F4kVtiGf0Y6Ts sPtmiPCBN+frmW5n4/8IJlcwJCGWVJY1DikoKraOhFcwtj9uPKv9dMZR/I4pYGKlozKflDDhF PsB92PNxLyCSdPWsf4+A5kz+x5YqHDkRbZn9S9ol+1CFmdu6x/W73jvSSYNX/xq4yJ+hzA21H ImDCypD2DJ5hyAS3gA88NGUZ9elroy79F+//dI2KUAmhS6dihZAK45gpEZTo+kx41qJyhF3nE hXeYAx3Cp6/uBI6yXakYl3a8mcinbn4in6tXpjuUs1wkH0sSFe7H3zKAPRoyW2otiU36+cjnC Eo32fmNkz1ECEQzMEy1jioSMwg2xbdEkxc0bbpOYJUWnNB5jAHLsv84TAAHRNY+ba0/06LMDb LpyoKr4rv2O92M8WWYKHupHbDa4MCJtGNsUqCFPtkHeuUzA5FZp4h4f0ghSgne1pmiGD01YN9 aU+AfXeFj8StvQsUR6nRchZG3n8y6OGTJ6nUpVlnR/fGtketxmW0lrBYpji4sNxv2j/zroqw3 HArURcdWVlptm3EfIxlSUElNNJeTSwLUkTdPzgzhOsV4qrvXwm4D3fhEWbbpiXp4VuuKVsHBB DrJxg9du/3x8XZtAnKjuTZhYxGQMur6dEHukdF0CGbTWevJNq7NhodIDMzAqEr4m7cPI6P0uL ahNbQ78kn6eWMZsvBg/IuiMpfEoVaL43CkfCGG+vtzkMZgtfSlDn+T+biDfTDCjTwzhDqwcli 18PnZwIKu3elKZS4d28Xh23Eeo7iGPwjsFi/GP2Ud10a6BwiTFKUYRmLmVfEERE9eNGP/0QPH fsuaKn7GdIWtET6AiJBcI8MAGDI0sJkjh45Z93eJixAd6e/uUi2KlkUVFjteh3WC36HeuVqVt JGh9cwarB6ff5UIAfedWmZUe1oHn2o1Eqe/IX+j195j4wJpit9EV6e0MOsmy4cpcgw== X-Spam-Status: No, score=-13.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, GIT_PATCH_0, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2021 21:08:09 -0000 Hi Paul, Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran: > Hi Harald, > > This looks good to me. OK for mainline and, dare I suggest, 11-branch? > > From a quick run through resolve.c, there are many places where the ext= ra > checks that you introduced in the patch have been implemented. This make= s > me wonder whether a function or macro might not make the relevant code m= ore > concise. I had thought about this in the past, too. Suitably chosen macros could help to make checking not only more concise, but also more robust and (hopefully) readable at the same time. What do you think about e.g. diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index e5d2dd7971e..f3d22b46a75 100644 =2D-- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -3885,6 +3885,8 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **); && CLASS_DATA (sym) \ && CLASS_DATA (sym)->attr.dimension \ && !CLASS_DATA (sym)->attr.class_pointer) +#define IS_CLASS_OBJ(sym) \ + (sym->ts.type =3D=3D BT_CLASS && sym->attr.class_ok) /* frontend-passes.c */ to be used to ensure that we are dealing with a CLASS object where attributes should already have been set up? Or use a better name? (IS_CLASS_OBJECT?) Thanks, Harald > Thanks for the patch > > Paul > > > On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran > wrote: > >> Dear all, >> >> there are a couple of NULL pointer dereferences leading to improper >> error recovery when trying to handle Gerhard's testcases involving >> SELECT TYPE and invalid uses of CLASS variables. >> >> The fixes look pretty obvious to me, but I'm submitting here to >> check if there is more that should be done here. >> >> (I was surprised to see that there are several different places >> involved by rather simple variations in the basic test case.) >> >> Regtested on x86_64-pc-linux-gnu. OK for mainline? >> >> Thanks, >> Harald >> >> > 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 09A733858019 for ; Tue, 28 Dec 2021 21:08:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09A733858019 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1n2Jhe-0009OT-9G for fortran@gcc.gnu.org; Tue, 28 Dec 2021 22:08:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366 Date: Tue, 28 Dec 2021 22:08:03 +0100 Message-ID: <5187e5f9-fc22-be34-a671-0268f718a78b@gmx.de> References: 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:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: Content-Language: en-US Cc: gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2021 21:08:17 -0000 Message-ID: <20211228210803.13OLyggH01z52oeC2zCiW_VIPoJGusJFIeEeDHV6c2A@z> Hi Paul, Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran: > Hi Harald, > > This looks good to me. OK for mainline and, dare I suggest, 11-branch? > > From a quick run through resolve.c, there are many places where the extra > checks that you introduced in the patch have been implemented. This makes > me wonder whether a function or macro might not make the relevant code more > concise. I had thought about this in the past, too. Suitably chosen macros could help to make checking not only more concise, but also more robust and (hopefully) readable at the same time. What do you think about e.g. diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index e5d2dd7971e..f3d22b46a75 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -3885,6 +3885,8 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **); && CLASS_DATA (sym) \ && CLASS_DATA (sym)->attr.dimension \ && !CLASS_DATA (sym)->attr.class_pointer) +#define IS_CLASS_OBJ(sym) \ + (sym->ts.type == BT_CLASS && sym->attr.class_ok) /* frontend-passes.c */ to be used to ensure that we are dealing with a CLASS object where attributes should already have been set up? Or use a better name? (IS_CLASS_OBJECT?) Thanks, Harald > Thanks for the patch > > Paul > > > On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran > wrote: > >> Dear all, >> >> there are a couple of NULL pointer dereferences leading to improper >> error recovery when trying to handle Gerhard's testcases involving >> SELECT TYPE and invalid uses of CLASS variables. >> >> The fixes look pretty obvious to me, but I'm submitting here to >> check if there is more that should be done here. >> >> (I was surprised to see that there are several different places >> involved by rather simple variations in the basic test case.) >> >> Regtested on x86_64-pc-linux-gnu. OK for mainline? >> >> Thanks, >> Harald >> >> >