From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 7685A387742E; Tue, 27 Jul 2021 07:52:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7685A387742E 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: 9tEGImZISScxIGzSFq31S/lLEAodyDd4zz6M/N0iwr50BpwBLgKo/+svcdr7bpkosH5TyybZRo qGcLjESouEY4h1oR6QcHdCyKMDHCxKtiMcUtPICjkLTdLOAWLoxkhIDgr9D5mGP3xG2mQgQBet nTb/oI38gIB6HecKK+hAy/IQcqyewp6vmQF9Y3KmRQbIGW1K1SylYmQ83pVkEfIR80ZaJBi2ww pkN43lt+hv1VqjmpcBPmowBvXTglJwK+TPh+kKzfv7WGUEOTbUSEhE9HK5ZtKzLVsn/N42GY+q cmMq/Hz0nt8HWTxhYAvDlypb X-IronPort-AV: E=Sophos;i="5.84,272,1620720000"; d="scan'208";a="66413707" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 26 Jul 2021 23:52:46 -0800 IronPort-SDR: aETj+LRNJl9ZDyEb0mHVkheJ0+aHp+EMcNU11DY5QlHNrd3obuly2NMlgFjIo4v2ZOIiU/UrvF rsNpXYRWnGvivw8J49dA880Q2Diqx9A5VQ7xzHy89OujhIfltHfTuCxQHY3wsNjY9f0rWeNelb 44rz3C6ty1oG4UNieqK2FZ6geTsLIVU69UVtiqtZhghmxdX1rqUOrz+/WlpIkvyDzSg5qpduT6 mA8iWFb3UMaYtLKw0tH04iLuKyyhhGKC7rHgGSpwnYsMibqGHSbO3CpEmH4AKpkLSP05IL4gxK l1c= 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> <217aa918-f12a-ebb5-2941-63b87c84b69c@codesourcery.com> From: Tobias Burnus Message-ID: <6ed7f80c-c59f-026a-c67f-933f5a3ea89c@codesourcery.com> Date: Tue, 27 Jul 2021 09:52:37 +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-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, KAM_SHORT, NICE_REPLY_A, 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: Tue, 27 Jul 2021 07:52:48 -0000 Hi Harald, On 26.07.21 23:55, Harald Anlauf wrote: > I've updated this for ALLOCATE/DEALLOCATE and STAT/ERRMSG, see > attached patch. This required updating the error messages of > two existing files in the testsuite. Thanks. >> Also affected: Some I/O items, a bunch of other stat=3D%v and >> errmsg=3D%v. > We should rather open a separate PR on auditing the related uses > of gfc_match. I concur =E2=80=93 I just wanted to quickly check how many %v are there =E2= =80=93 besides %v, there are also direct calls to gfc_match_variable. Can you open a PR? >>>> if ((stat->ts.type !=3D BT_INTEGER >>>> && !(stat->ref && (stat->ref->type =3D=3D REF_ARRAY >>>> || stat->ref->type =3D=3D REF_COMPONE= NT))) >>>> || 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 adde= d >>> 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 reaso= ning. > Well, there is some text in the standard that I added in front of > the for loops, and this code is now exercised in the new testcase. The loops are clear =E2=80=93 but the '!stat->ref || (...ref->type !=3D ARRAY || ref->type !=3D COMPONENT))' is still not clear to me. * * * Can you add the (working) test: allocate (A, stat=3Dy%stat%kind) ! { dg-error "cannot be a constant" } deallocate (A, stat=3Dy%stat%kind) ! { dg-error "cannot be a constant" = } to your testcase gcc/testsuite/gfortran.dg/allocate_stat_3.f90 ? And also the following one, which does not get diagnosed and, hence, later gives an ICE during gimplification. type tc character (len=3D:), allocatable :: str end type tc ... type(tc) :: z ... allocate(character(len=3D13) :: z%str) allocate (A, stat=3Dz%str%len) deallocate (A, stat=3Dz%str%len) To fix it, I think the solution is to do the following: * In gfc_check_vardef_context, handle also REF_INQUIRY; in the for (ref =3D e->ref; ref && check_intentin; ref =3D ref->next) loop, I think there should be a if (ref->type =3D=3D REF_INQUIRY) { if (context) gfc_error ("Type parameter inquiry for %qs in " "variable definition context (%s) at %L", name, context, &e->where); return false; } (untested) I assume (but have not tested it) that will give two error messages for: allocate (A, errmsg=3Dz%str%len) deallocate (A, errmsg=3Dz%str%len) one for the new type-param-inquiry check and one for !=3D BT_CHARACTER if you want to prevent the double error, consider to replace gfc_check_vardef_context (...); by if (!gfc_check_vardef_context (...)) goto done_errmsg; > Regtested on x86_64-pc-linux-gnu. OK? LGTM - except for the two testcase additions proposed above and fixing the ICE. If you are happy with my changes and they work, feel free add them and commit without further review. In either case, I have the feeling we are nearly there. :-) Thanks for the patch and the review-modification-review-... patience! Tobias > Fortran: ICE in resolve_allocate_deallocate for invalid STAT argument > > gcc/fortran/ChangeLog: > > PR fortran/101564 > * match.c (gfc_match): Fix comment for %v code. > (gfc_match_allocate, gfc_match_deallocate): Replace use of %v code > by %e in gfc_match to allow for function references as STAT and > ERRMSG arguments. > * resolve.c (resolve_allocate_deallocate): Avoid NULL pointer > dereferences and shortcut for bad STAT and ERRMSG argument to > (DE)ALLOCATE. > > gcc/testsuite/ChangeLog: > > PR fortran/101564 > * gfortran.dg/allocate_stat_3.f90: New test. > * gfortran.dg/allocate_stat.f90: Adjust error messages. > * gfortran.dg/implicit_11.f90: Adjust error messages. ----------------- 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