From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by sourceware.org (Postfix) with ESMTPS id 069DD3858419; Wed, 29 Dec 2021 11:45:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 069DD3858419 Received: by mail-qv1-xf2d.google.com with SMTP id q3so18959692qvc.7; Wed, 29 Dec 2021 03:45:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dN0Lh3b6e/qWu2tekt10Ay6TLyYbpGN1VjICL1h50+Q=; b=ivcVn0g0OyzMIIOtPXDFMhx5LZvENTMnT1qyYRfTatszk08EV9uyUTIQOR7qd+KJzH m3k7WmyGJHvTiuvhIXl7gayLhNXaSTuX6/QCxQ7hkAlEg+kRnQ7tk07nGdIm+DxZ3v2Y TfQ3gNsdBiV1JvJW967F7YTVxjoW73BSGTexNHTKbj+HtugTj6bfMobxHGEY1sxaYPWI L2Kfa04Gw/MKXhkLnQHqvql+80oyh9dZmjn96Zeimj0TA0M26Veby70YCs59EHrTtk1m KFwGg5OY0TJ497xsBMCyYh0hplUFX9Gi6JL2qQYceXDW3m94HnKtvbaQlX02gFensDvV 4fmg== X-Gm-Message-State: AOAM533DES+nJNqj0DPk1jtdhGuKLEvHlJiZosDwclEpUaWT/3C17qMs gOZF+D3RFq+7zQW2ZjOQZRtmfZUSFqS4jTDSHOY= X-Google-Smtp-Source: ABdhPJzAkI3LZULeWFX7m7ah71fqHTwXVnfW/LSRhjsjT136gRpis9ks6PT6WkuG43AzfneFX3k6GHicD3/9kOpntf0= X-Received: by 2002:a05:6214:2469:: with SMTP id im9mr22903953qvb.49.1640778311611; Wed, 29 Dec 2021 03:45:11 -0800 (PST) MIME-Version: 1.0 References: <5187e5f9-fc22-be34-a671-0268f718a78b@gmx.de> In-Reply-To: <5187e5f9-fc22-be34-a671-0268f718a78b@gmx.de> From: Paul Richard Thomas Date: Wed, 29 Dec 2021 11:45:02 +0000 Message-ID: Subject: Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366 To: Harald Anlauf Cc: gcc-patches , fortran X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, HTML_MESSAGE, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 29 Dec 2021 11:45:13 -0000 Hi Harald, That is the sort of thing that I had in mind. Is it worth adding the check for CLASS_DATA? I cannot remember if that is made redundant by the test of the class_ok attribute. Cheers Paul On Tue, 28 Dec 2021 at 21:08, Harald Anlauf wrote: > 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 < > fortran@gcc.gnu.org> > > 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 > >> > >> > > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein