From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 256383858002; Tue, 23 Mar 2021 17:34:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 256383858002 Received: by mail-lj1-x229.google.com with SMTP id z25so26679462lja.3; Tue, 23 Mar 2021 10:34:22 -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=9pbLtsz6BrlRMUeot4ADhWYwbcaXJGiWl6y07PQ5FM8=; b=rW2EvVVRPcxPcY4FpeXVmIXIljyDPjML6a41YfdqP2CRzb2QhOdwQtyGJheYfTtiGr DIIk4eXWnCAL0nIw9Wla+Xd9PVhX61qLJP7oQmJWOI4aRwBk3fvYuKbUyNPtky+fZG2n 61OV6Q180O204Z4H0SJxSxDt0OOq/BkOQVhU0NtqKumhc8U7CQfsBRcwCI8eYNKkbmeV lH//F4joAQ/k3GjVDkcbMxokXvlYb7NsZnFniwzayrPytO0K8lNViRuQvmuczUFLuqNi 9XxSDMJq0ocbN0V02HS/NPD4wIZT/oVEBzH7eu222MjxNfmxEx35F7iqdY66Tz1bPNiA OdDw== X-Gm-Message-State: AOAM532H+FERn9oZJFCzCLRlLDkOOCRmrfypc6pWrlhdU9PLXyO8TBeP 2U1GXV484IDD4wTv1cVFUAcDL9zkWwGd+lZoSUc= X-Google-Smtp-Source: ABdhPJycyVtBJ7Cwb22I7i9B0sY5mBhmEFUCCqzLd8ayrYhpjJSrhbB+4afoaw9D8feMuMd8dF5jXYzlfqIJHAzySB8= X-Received: by 2002:a2e:3608:: with SMTP id d8mr3828609lja.21.1616520860834; Tue, 23 Mar 2021 10:34:20 -0700 (PDT) MIME-Version: 1.0 References: <7f4a2fe7-4880-312b-4a05-9578fa431e7c@codesourcery.com> In-Reply-To: <7f4a2fe7-4880-312b-4a05-9578fa431e7c@codesourcery.com> From: Paul Richard Thomas Date: Tue, 23 Mar 2021 17:34:09 +0000 Message-ID: Subject: Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651] To: Tobias Burnus Cc: gcc-patches , fortran X-Spam-Status: No, score=-8.4 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:34:23 -0000 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 PR93660 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, NULL= ) > || !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 intrin= sic 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=BCnchen > Registergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thoma= s Heurung, Frank > Th=C3=BCrauf > --=20 "If you can't explain it simply, you don't understand it well enough" - Albert Einstein