From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 358EC3858002; Tue, 23 Mar 2021 17:36:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 358EC3858002 Received: by mail-lf1-x12c.google.com with SMTP id b4so3934500lfi.6; Tue, 23 Mar 2021 10:36:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F9HDwdrXNJQ4ik1tgGL3HLKb3pa6Jn88kLKboThNoCI=; b=AhS00Lej6NHJj2picIPlnxcO+RMyKy+9bh9KbXsSZWSkxdJ/E5NKAjgrgcclf+QZcG tU4Z7QltCTW7SQrf3d7wGMTjWpZVx/SQCIvjLdBLx8pEi5i8pd5sWL0CHjM0f4a6woAG 4mt8isjJdVDBE1FiW2PUYx19/usZoBOApVYwKr/sa+OqEQcDE542BFDlYwVcn/D9chNL Oxo9mjGDrr9Qdcj8YrTYRJSrYGW5kyKUy2WJamqYNtqVQ2byMJH+dkLINfXuDJDo1GDU shKjXN8/11MGcBO+fz/lbaCK6J7/RihTvnDk5QgZtl6+MAjRv2jpM/lOSxlahyHkF/42 IYsA== X-Gm-Message-State: AOAM530iZitIKifDRENmRergMHwL3mDJMM0thVGZqaes+277OBqrq7Ii KwIQc1k9Ew17odHcAgqAkQCynOdjbjRY4gET/Xu3cszkrYg= X-Google-Smtp-Source: ABdhPJz3YjPF/LnkUm/mmW12WEcmhIzmjicfU4biKlehs05qRA6/wHo8KymDXXz/XlE9Gz3aFZcsaf6glHB5OL5mjtM= X-Received: by 2002:a05:6512:1310:: with SMTP id x16mr3089633lfu.19.1616520964058; Tue, 23 Mar 2021 10:36:04 -0700 (PDT) MIME-Version: 1.0 References: <7f4a2fe7-4880-312b-4a05-9578fa431e7c@codesourcery.com> In-Reply-To: From: Paul Richard Thomas Date: Tue, 23 Mar 2021 17:35:52 +0000 Message-ID: Subject: Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651] To: Tobias Burnus Cc: gcc-patches , fortran X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Tue, 23 Mar 2021 17:36:07 -0000 Cancel the thought on my patchlet null_5.f90 fails on excess errors. Paul On Tue, 23 Mar 2021 at 17:34, Paul Richard Thomas < paul.richard.thomas@gmail.com> wrote: > Hi Tobias, > > I took something of a detour in reviewing this patch. Although short, > understanding it is not straightforward! > > Your patch works as advertised and regtests OK (with the patch for PR9366= 0 > on board as well). Is NULL the only case where this can happen? > Just to aid my understanding, I tried: > diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c > index a6df885c80c..f4c43a7c38b 100644 > --- a/gcc/fortran/primary.c > +++ b/gcc/fortran/primary.c > @@ -3922,6 +3922,9 @@ gfc_match_rvalue (gfc_expr **result) > if (m =3D=3D MATCH_NO) > m =3D MATCH_YES; > > + if (!strcmp (sym->name, "NULL") || !strcmp (sym->name, "null")) > + sym->attr.intrinsic =3D 1; > + > break; > > generic_function: > > which also works and regtests OK. (I couldn't remember whether sym->name > is upper or lower case at this stage.) > > Thus, I THINK that your patch is OK and haven't managed to find any tests > which it breaks. I'll come back with a more definitive opinion tomorrow. > > Paul > > > > On Fri, 19 Mar 2021 at 08:51, Tobias Burnus > wrote: > >> See PR for some analysis. The problem is that during >> gfc_intrinsic_func_interface, sym->attr.flavor =3D=3D FL_PROCEDURE, >> hence, attr.intrinsic is not set =E2=80=93 but later when parsing >> 'null()', gfortran calls: >> >> if (sym->attr.proc !=3D PROC_INTRINSIC >> && !(sym->attr.use_assoc && sym->attr.intrinsic) >> && (!gfc_add_procedure(&sym->attr, PROC_INTRINSIC, sym->name, NUL= L) >> || !gfc_add_function (&sym->attr, sym->name, NULL))) >> return MATCH_ERROR; >> >> The gfc_add_procedure call fails as 'sym' is use-associated and >> may not be modified. >> >> The obvious solution to also set attr.intrinsic for FL_PROCEDURE fails >> in multiple ways, e.g. for gfortran.dg/char_length_16.f90 which has: >> CHARACTER (LEN(ITEMVAL)) :: ITEM >> INTRINSIC LEN >> the error is that INTRINSIC has been speicified twice. It also affects >> the error diagnostic in for generic resolution due to (I think): >> if (sym->attr.intrinsic) >> return gfc_intrinsic_func_interface (expr, 0); >> For gfortran.dg/allocatable_scalar_11.f90 the specific >> =E2=80=98array=E2=80=99 argument of =E2=80=98allocated=E2=80=99 intri= nsic at (1) must be a variable >> gets replaced by the generic >> Generic function 'allocated' at (1) is not consistent with a specific >> intrinsic interface >> >> I have now tried it as shown. I think attr.function was not set, but >> am not sure. But setting it again for FL_PROCEDURE looks sensible. >> >> I am far from certain that now everything fits together, but I do hope >> that nothing fails which did work before ... >> >> OK for mainline? And after waiting a while for GCC 10? >> >> Tobias >> >> PS: I did see once a fail for pr93792.f90 (additional error as 't' in >> type(t) >> is not known) =E2=80=93 but I could not reproduce it; the error is valid= but >> later runs >> stopped with 'cannot open module file' and did not reach that follow-up >> error. >> >> ----------------- >> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 M=C3=BCnche= n >> Registergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thom= as Heurung, Frank >> Th=C3=BCrauf >> > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein > --=20 "If you can't explain it simply, you don't understand it well enough" - Albert Einstein