From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 1CAB33853C02; Fri, 23 Jul 2021 08:17:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CAB33853C02 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 6L1MYOcRTaxJrNI8caICtv1/lLqHevWYk1L5Ag9tdRCVpt6PwmDTfUHVzfaWDujbfvJYSiSerD Mbrei9hVYJ2YNremclcaupq9Gi7871yOMki5omOuSvMXvHNMRBYBfolLGEjnyHSPnfCUqCwAuD V94+sfMBacdoe5kfpduo6mrjKMmX4aivI3g6jMgY0T1uf3n5IbOjWmkJKj7Yn5xkL18HhIJgC9 IR5VQXYG8aKikeXXonmWZGG5+ax0X41nSkBOwhp2RrccLf6ibEvqQBcyZqvy51Wg0jzmlS40WZ zKXyc/4BuLtpmUc8TSQH3wLX X-IronPort-AV: E=Sophos;i="5.84,263,1620720000"; d="scan'208";a="63845257" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 23 Jul 2021 00:17:12 -0800 IronPort-SDR: 8+q4Ncxy48r+qd4uBzdGZ4l17q4qzdmC2qRwX3CqsJCMyAlb4I43Wsy0zl244iXdIeHraiHWA9 ykGuShJQGmA+mDQ27rvdxEACn4zB4V/OBuIpiKJ/w99ofgYfjedjvG+NpPa7My7ck3I2NFpdAw bs3/sRPuzhtQa1fKKBJ8+vsjSm0WlHzM9JXiCk2KVhhdrrfoJL8FSuXdVUBDE5LIpbzmSRzJ53 XTW+ixUlmhGhCWWwtCdk6pojuBogk9pt8V2urzh7RA6Zq+ZLpJdtdIzduUKdxIafWl1rl6WB8L /QM= Subject: Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169 To: Harald Anlauf CC: fortran , gcc-patches References: <9b6187f0-d3dd-bb2d-d6f3-ada831cdecf0@codesourcery.com> From: Tobias Burnus Message-ID: <217aa918-f12a-ebb5-2941-63b87c84b69c@codesourcery.com> Date: Fri, 23 Jul 2021 10:17:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable 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=-5.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 08:17:15 -0000 Hi Harald, On 22.07.21 21:50, Harald Anlauf wrote: > I am afraid we're really opening a can of worms here.... which is not too bad if there are only two earthworms in there ;-) >> Additionally, I wonder whether that will work with: > I think a "working" testcase for this could be: > > program p > implicit none > integer, target :: ptr > integer, pointer :: A > allocate (A, stat=3Df()) > print *, ptr > contains > function f() > integer, pointer :: f > f =3D> ptr > end function f > end Indeed that I meant. > This works as expected with Intel and AOCC, but gives a > syntax error with every gfortran tested because of match.c: > > alloc_opt_list: > m =3D gfc_match (" stat =3D %v", &tmp); I think we can simply change that one to %e; the definable check should ensure that any non variable (in the Fortran sense) is rejected. And we should update the comment for %v / match_variable to state that it does not include function references. In some cases, like with OpenMP, we still do not want to match functions, hence, changing match_variable is probably not what we want to do. Additionally, for all %v replaced by %e we need to ensure that there is a definable check. (Which should be there already as INTENT(IN) or named constants or ... are also invalid.) Also affected: Some I/O items, a bunch of other stat=3D%v and errmsg=3D%v. Talking about errmsg: In the same function, the same check is done for errmsg as for stat =E2=80=93 hence, the patch should update also errmsg. >> Additionally, I have to admit that I do not understand the >> following existing condition, which you did not touch: >> >> if ((stat->ts.type !=3D BT_INTEGER >> && !(stat->ref && (stat->ref->type =3D=3D REF_ARRAY >> || stat->ref->type =3D=3D REF_COMPONENT)= )) >> || stat->rank > 0) >> gfc_error ("Stat-variable at %L must be a scalar INTEGER " >> "variable", &stat->where); >> >> I mean the ts.type !=3D BT_INTEGER and stat->rank !=3D 0 is clear, >> but what's the reason for the refs? > Well, that needs to be answered by Steve (see commit 3759634). (https://gcc.gnu.org/g:3759634f3208cbc1226bec19d22cbff989a287c3 (svn r145331)) The reason for the ref checks is unclear and seem to be wrong. The added testcases also only use 'x' (real) and n or i (integer) as input, i.e. they do not exercise this. I did not look for the patch email for reasoning= . Thanks, Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955