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 >> >> >