From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 057D6385781B; Fri, 12 Feb 2021 13:37:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 057D6385781B Received: by mail-lj1-x234.google.com with SMTP id a25so11596598ljn.0; Fri, 12 Feb 2021 05:36:59 -0800 (PST) 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=lCUMS0wMPbdh/+mZQzmRaKmvO9zC/VkmAFi3umnhEl0=; b=di7CtJvus469MUMxGaybJ//hwmNL9xwGmDFTA+prZr1MSgxNewIa4Jw3RvnphW7zLL hou7vR9F0g17oKfjBM8KEaH622DKAYNa40wZ/OpyVy5z+m4b9VD7MXGy1v1nwBRBJa3O Xr5C/zaLLxOtLLJkYCiVZ6OpdKtjGyWHT4bplA0sJVCoEmPzQ1fZjC6aMd3uOmSc/tdy xTBPy1MVDvIk26SoO/ZEVcAjmCtwXyOTDQDDvlTIan/nsFaB2ayt0/qIJgPjz3cJXwYx rljK7MZTj8y8Gj9QpCCw5hnbhJA38zNQvr3Fy/9sSaYGoW/GEF/5VSAkV923VwYTtCJm hLrw== X-Gm-Message-State: AOAM5332BQMb3EI7uV4DIIo5BDAS8OMupimfyzJiabE9W3hSeAznj1LA 4dsO+j6C/BAt/oHVOXBSy0mpYUhREms0b+ZKn3o= X-Google-Smtp-Source: ABdhPJz5lD71YbouH6edPZXLxNhSJRHMz2tlnYwUuqcTfAEb425+GUjvGaVXsb21OMUOy8qdBJz1LZFigOtjlIporAM= X-Received: by 2002:a2e:908c:: with SMTP id l12mr1716006ljg.21.1613137018644; Fri, 12 Feb 2021 05:36:58 -0800 (PST) MIME-Version: 1.0 References: <33375e26-9020-328a-5d64-4bfeb4862369@codesourcery.com> <96a727b0-311e-bbac-a9a2-dfaf0e18b7e0@codesourcery.com> In-Reply-To: <96a727b0-311e-bbac-a9a2-dfaf0e18b7e0@codesourcery.com> From: Paul Richard Thomas Date: Fri, 12 Feb 2021 13:36:46 +0000 Message-ID: Subject: Re: [Patch, fortran] PR98897 - Erroneous procedure attribute for associate name To: Tobias Burnus , Damian Rouson Cc: gcc-patches , "fortran@gcc.gnu.org" X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Fri, 12 Feb 2021 13:37:02 -0000 Hi All, Following off-list discussion with Tobias, I have committed the patch as submitted to 10- and 11-branches. A rather general problem with parsing and matching, which arose from the discussion, has been shunted into PR99065. If possible, I intend to fix this by two pass parsing/matching of all contained procedures; first all specification blocks and then, on the second pass, the code blocks. This should eliminate the need for the likes of parse.c(gfc_fixup_sibling_symbols) and some similar fixups in resolve.c. Regards Paul On Tue, 2 Feb 2021 at 15:56, Tobias Burnus wrote: > Hi, > > first, I have attached a new example =E2=80=93 it works if I move bar/hel= lo up, > but if 'foo' comes first, it fails. I think it is valid. > (ifort 19 also compiles it.) > > Sorry for trying hard to find examples where it does not > work =E2=80=93 but I have simply the feeling that resolving things > during parsing cannot work in all cases. > > On the other hand, I think your patch at least does not break > valid code as I had feared before. :-) > Thus, in that sense it would work for me. > > * * * > > Regarding my previous examples, they are invalid because of: > > C1105 (R1105) expr shall not be a designator of a procedure pointer > or a function reference that returns a procedure pointer. > > However: > > On 02.02.21 16:05, Paul Richard Thomas via Fortran wrote: > > > In foo.f90, if I remove > > call var(i) ! { dg-bogus "VARIABLE attribute of 'var' conflicts > with > > PROCEDURE attribute" } > > gfortran correctly complains > > 23 | associate (var =3D> bar()) > > | 1 > > Error: Selector at (1) has no type > > Which is not quite right. bar() has a type =E2=80=93 it returns > a procedure pointer; even in cases where gfortran could > know at parse time, it does not diagnose C1105 but shows > an odd error instead. > > > ifort complains: > > ../pr98897/foo.f90(11): error #8179: The procedure pointer and the > > procedure target must both be functions or subroutines. > > res =3D> double > Okay, we found a bug in ifort. 'double' and 'res' have the same > interface by construction =E2=80=93 and both are subroutines. > It seems to be a similar bug to the ifort bug I got before: > When 'double' is parsed, ifort expects that 'precision' follows > ('double precision'). > > > The responses from both compilers to foo3.f90 are the same. > > (I forgot to comment/remove 'procedure(bar) :: var' when > playing around.) Again, this code violates C1105 =E2=80=93 and the > error messages are still odd. > > > On Tue, 2 Feb 2021 at 13:59, Tobias Burnus > wrote: > > On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote: > >>> Regtests with FC33/x86_64 - OK for master (and ....)? > >>> Fortran: Fix calls to associate name typebound subroutines [PR98897]. > >>> > >>> 2021-02-02 Paul Thomas > >>> > >>> gcc/fortran > >>> PR fortran/98897 > >>> * match.c (gfc_match_call): Include associate names as possible > >>> entities with typebound subroutines. The target needs to be > >>> resolved for the type. > >>> > >>> gcc/testsuite/ > >>> PR fortran/98897 > >>> * gfortran.dg/typebound_call_32.f90: New test. > ----------------- > 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