From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id AA5FD386187B; Tue, 2 Feb 2021 15:56:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AA5FD386187B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Tobias_Burnus@mentor.com IronPort-SDR: zMSPocma5G5Np3P46ZZZ3ND5yFjHGkRBp8v5Mx2XYOWeDBn77LbtjALP9Z5LBsxUR5TKYVFHYs aXNMeNiI78lA1VBj1X7rQywM9d2uknnTo2x+Y8/h0CJbOVNDc6VblUPJw0SOKUjeTX1VO2VTLB 5vE8EWqmZNNDd1OmTrk4SB6/QKLeAOELDjnVG6eyIBLYWJ+/5+kR52gsNgxp6ouLYSp04BXXj/ jQhWGh24H/6O9MIYGMcAYn+xL0fVlxdpfbyTmc9O0lLm+vKLmUEOlYnzgaqJ/F7UmUaj6flL5e x8g= X-IronPort-AV: E=Sophos;i="5.79,395,1602576000"; d="f90'?scan'208";a="57679514" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 02 Feb 2021 07:56:55 -0800 IronPort-SDR: SzRjXJ/gOXRKJHGIer9PlA5dpOZxMwepJ1doV6xYQuoc12OvYxraRWRipVAnXHOSOZvRQA1egX msD52US0kgSmbaXH9Q52c/uXgpc4Z1/LVVU1xpPkSoA2NMjnBot2esaMzxssWJ4O508wcTsOVF lrVVaDhlKaRUJJ4nohOMuPMGQ5Gwnz9P12c3p9aLDv0X0P/6YDVQZRxaGirpcSYTE3uY5w1Lme 7OwvVj0sNCJYJ790XfuSVK+n7lvxz9JfXjlhaNC1drFte9X+IgVrlRaB4NKAQ4L21ltYn5nDO7 0HE= Subject: Re: [Patch, fortran] PR98897 - Erroneous procedure attribute for associate name To: Paul Richard Thomas CC: gcc-patches , "fortran@gcc.gnu.org" References: <33375e26-9020-328a-5d64-4bfeb4862369@codesourcery.com> From: Tobias Burnus Message-ID: <96a727b0-311e-bbac-a9a2-dfaf0e18b7e0@codesourcery.com> Date: Tue, 2 Feb 2021 16:56:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------BD7861C1C6252724484CD1D4" Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-05.mgc.mentorg.com (139.181.222.5) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 02 Feb 2021 15:56:59 -0000 --------------BD7861C1C6252724484CD1D4 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, first, I have attached a new example =E2=80=93 it works if I move bar/hello= 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 wi= th > 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 wrot= e: > 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 R= egistergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thomas H= eurung, Frank Th=C3=BCrauf --------------BD7861C1C6252724484CD1D4 Content-Type: text/x-fortran; charset="UTF-8"; name="varfunc.f90" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="varfunc.f90" module m implicit none type t contains procedure, nopass :: hello end type t contains subroutine foo() associate (var => bar()) call var%hello() end associate end subroutine foo subroutine hello print *, 'Hello' end type(t) function bar() end end module m program test use m call foo() end program test --------------BD7861C1C6252724484CD1D4--