From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by sourceware.org (Postfix) with ESMTPS id F40993858C55; Sun, 3 Mar 2024 20:20:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F40993858C55 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F40993858C55 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.17.22 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709497249; cv=none; b=JmjZtRHzGJ3EgA3w8jVTZBx6Tm9FVARRS2M7TjURd1LYWBNAJlkG9q4gNcwKdK3Sbjj5TqKIqedyADHWWFKO+Qy1fhuY2AnCLKjNTl4CRP0Af4Tb1rV1/X96zUyWWD/M+0GZRx8G0mjPyq0JGB5d8uOldj0W1H4xUAHByqOWYfk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709497249; c=relaxed/simple; bh=YfywwLDXKkWZ2IvdJ2ZG+zvUldKBJs+0VU1Fhxuh6TM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=BEdtSm3KyY4OCLJ3j0s+I4+FS1SPuM1PkP3GkBlFJ47IEFOCnIV/UEQn2ZLcFdHShNyoiPYSon9zJ7jsZ4Dvnyx9R3xj7lPKquDjL7Y2OxRnrYbYSjrWvcg59zD8wYO3WPyOXsVhbIwMgjatC2BGe4HmNKVu0di2HhAUXapNXmE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1709497240; x=1710102040; i=anlauf@gmx.de; bh=YfywwLDXKkWZ2IvdJ2ZG+zvUldKBJs+0VU1Fhxuh6TM=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=uiv+Fv/7FWyRsKpJ5Up0O5R+L/outfciWfTgSVHCY/S2r3HhSfgnpONcuxqOTGqT ebpjDEPlAGUrV6OPzZURgBpUqFlVQ7qqr7CTHd4NoPupG7Q5pBGLRSfr6s5pq96Py 3g6nHMc07jPnzP4yU19YOpFVce4G64/8yU1iARSnjVT0Ic+WdlAn3fXNj9NkYhxiw 1CVETslvmLxmaRGJuwge6q1tAJbQVsVqsDG+ZumnP1nfF5ea4R8Vl7/EQdftd1oq6 JlP57Y/ld1X9iu3VsYYiMLCU4eDv1xVXP5pxQnfVepWt1BXrLJogMlB9wUPlnqWYV nlGA5/292Oz/cc8Y0w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.251.8.172]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MY68T-1rMC970ZOX-00YTcq; Sun, 03 Mar 2024 21:20:40 +0100 Message-ID: Date: Sun, 3 Mar 2024 21:20:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() ) To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches , Steve Kargl Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <674cfbf0-a95d-4433-a025-29e78dc0bcef@gmx.de> Content-Language: en-US From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:uIOOs1PobM69ImqLugwTHwxfyhmuM/ogxlhYTF8r/0eWvQmkRAC wyhP98DJM+x20hZTJYLWGuETYc098MTCp05j/mdwtuIXk2BIEBFzFPuDyM4UO/UNp2SraPI U9/Qh7Nt1fEqCdUeDGPOTrM362h3PIl49S13OzzZ5J1x0fsd9dMHcRTwKtu3LXgojdlSxAs h9tEY1xiOuE0iFh4X0K0A== UI-OutboundReport: notjunk:1;M01:P0:VpCmb3xlT4k=;PaxVQBzhtvY9MLxq0CWrf4Dr8QS 24JMTnPOXpC/mS2lcokSPdM1JRCX+mKE7RiHt2Jk6NpQa4x9Aa1hw6UgxCfkYcNoadpD/KDTe XDVfyC8YNl0sGHAe/l9GSiz9bhG3cUEjoL1dnu14lbs4dhywoJ7Hx+En3E6nilStq55jEDUdV BHXjYCk7mk5gmZEA379p1w6ksI50uDx78APjeil46sOtHWTPMMvHQ2TJx7LhR+F0H7derj9JA A6JfG+tX3vHb14Yy7sR/lMXOOIWR6Bo9mrW86zH++Of8uSouhBv4PlsrWBKXzedqu5gL3UOJh wcltnk1LYrwSDXj6ki6cgC8+RxCeuN8G/tBM17IpJBaFLE9IsNJrR8qMUGZeQpOSIVi/C2Ilp +AlkXuGM0oQeyR5bRQqq2jljrWmcHYLpZmvvyEI9vPZ3d1XfgR0OXH4cDov9zsjMbwh0MdMdD s/z9C/1u+A2Hul1KoGBg+ZCLMxYSKY6M71oEprBAzOcn9VHZ+xG8Y/R2v5zULvN9VbHDmpNxT WV49cFEpTRgFPIGpcIMlEx5X59bbdwdOvECinGBuYKHL05qBt0W7B8c90AUcv8ytovD/T4cLI i3kru6IPUrvJrfub2Jgm155fq9SySMIq2LaLApXxSe2enbOB8TVeMEg5xaBiryg8QMIouBvO9 84vUpKyzEIEzodF8E2359giMY9manTQ/NAcSjANcQfaEO1Izdk1uCnFFCzimgbphQ+CPC+m3C L/P7SPAJj4rs6/l9915kFtGFYzsUOA01Bs0MyX2V/NMfj3v6Wuj2LfKVnShDHBMQ1mZR7mwsi gJxFTqw7YOvNZYTOlx4kN3Ag0213FDyOgMMJcynG4FtYc= X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Paul, welcome back! On 3/3/24 17:04, Paul Richard Thomas wrote: > Hi Harald, > > Please find an updated version of the patch that rolls in Steve's patch = for > PR114141, fixes unlimited polymorphic function selectors and cures the > memory leaks. I apologise for not working on this sooner but, as I infor= med > you, I have been away for an extended trip to Australia. > > The chunks that fix PR114141 are picked out in comment 14 to the PR and = the > cures to the problems that you found in the first review are found at > trans-stmt.cc:2047-49. > > Regtests fine. OK for trunk, bearing in mind that most of the patch is r= ing > fenced by the inferred_type flag? I would say that it is almost fine. Two things that I found: - Testcase associate_65.f90 does not compile with -std=3Df2023, because IMAG is a GNU extension, while AIMAG is the standard version. Could you please adjust that? - I think the handling of parentheses and functions returning pointers does not work correctly. Consider: program paul implicit none type t integer :: i end type t type(t), pointer :: p(:) allocate (p(-3:3)) associate (q =3D> p) print *, lbound (q), ubound (q) ! Should print -3 3 (OK) end associate associate (q =3D> set_ptr()) print *, lbound (q), ubound (q) ! Should print -3 3 (OK) end associate associate (q =3D> (p)) print *, lbound (q), ubound (q) ! Should print 1 7 (OK) end associate associate (q =3D> (set_ptr())) ! <- are these parentheses lost? print *, lbound (q), ubound (q) ! Should print 1 7 end associate contains function set_ptr () result (res) type(t), pointer :: res(:) res =3D> p end function set_ptr end While the first three variants give the right bounds, the last version - after applying your patch - is mishandled and the testcase now prints: -3 3 -3 3 1 7 -3 3 Both NAG and Intel support my expectation, namely that the last line should equal the next-to-last. Can you recheck the logic for that particular corner case? With these points addressed, your patch is OK from my side. Thanks for the patch and your endurance! Harald > Cheers > > Paul > > > On Mon, 8 Jan 2024 at 21:53, Harald Anlauf wrote: > >> Hi Paul, >> >> your patch looks already very impressive! >> >> Regarding the patch as is, I am still trying to grok it, even with your >> explanations at hand... >> >> While the testcase works as advertised, I noticed that it exhibits a >> runtime memleak that occurs for (likely) each case where the associate >> target is an allocatable, class-valued function result. >> >> I tried to produce a minimal testcase using class(*), which apparently >> is not handled by your patch (it ICEs for me): >> >> program p >> implicit none >> class(*), allocatable :: x(:) >> x =3D foo() >> call prt (x) >> deallocate (x) >> ! up to here no memleak... >> associate (var =3D> foo()) >> call prt (var) >> end associate >> contains >> function foo() result(res) >> class(*), allocatable :: res(:) >> res =3D [42] >> end function foo >> subroutine prt (x) >> class(*), intent(in) :: x(:) >> select type (x) >> type is (integer) >> print *, x >> class default >> stop 99 >> end select >> end subroutine prt >> end >> >> Traceback (truncated): >> >> foo.f90:9:18: >> >> 9 | call prt (var) >> | 1 >> internal compiler error: tree check: expected record_type or union_type >> or qual_union_type, have function_type in gfc_class_len_get, at >> fortran/trans-expr.cc:271 >> 0x19fd5d5 tree_check_failed(tree_node const*, char const*, int, char >> const*, ...) >> ../../gcc-trunk/gcc/tree.cc:8952 >> 0xe1562d tree_check3(tree_node*, char const*, int, char const*, >> tree_code, tree_code, tree_code) >> ../../gcc-trunk/gcc/tree.h:3652 >> 0xe3e264 gfc_class_len_get(tree_node*) >> ../../gcc-trunk/gcc/fortran/trans-expr.cc:271 >> 0xecda48 trans_associate_var >> ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2325 >> 0xecdd09 gfc_trans_block_construct(gfc_code*) >> ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2383 >> [...] >> >> I don't see anything wrong with it: NAG groks it, like Nvidia and Flang= , >> while Intel crashes at runtime. >> >> Can you have another brief look? >> >> Thanks, >> Harald >> >> >> On 1/6/24 18:26, Paul Richard Thomas wrote: >>> These PRs come about because of gfortran's single pass parsing. If the >>> function in the title is parsed after the associate construct, then it= s >>> type and rank are not known. The point at which this becomes a problem= is >>> when expressions within the associate block are parsed. primary.cc >>> (gfc_match_varspec) could already deal with intrinsic types and so >>> component references were the trigger for the problem. >>> >>> The two major parts of this patch are the fixup needed in >> gfc_match_varspec >>> and the resolution of expressions with references in resolve.cc >>> (gfc_fixup_inferred_type_refs). The former relies on the two new >> functions >>> in symbol.cc to search for derived types with an appropriate component= to >>> match the component reference and then set the associate name to have = a >>> matching derived type. gfc_fixup_inferred_type_refs is called in >> resolution >>> and so the type of the selector function is known. >>> gfc_fixup_inferred_type_refs ensures that the component references use >> this >>> derived type and that array references occur in the right place in >>> expressions and match preceding array specs. Most of the work in >> preparing >>> the patch was sorting out cases where the selector was not a derived t= ype >>> but, instead, a class function. If it were not for this, the patch wou= ld >>> have been submitted six months ago :-( >>> >>> The patch is relatively safe because most of the chunks are guarded by >>> testing for the associate name being an inferred type, which is set in >>> gfc_match_varspec. For this reason, I do not think it likely that the >> patch >>> will cause regressions. However, it is more than possible that variant= s >> not >>> appearing in the submitted testcase will throw up new bugs. >>> >>> Jerry has already given the patch a whirl and found that it applies >>> cleanly, regtests OK and works as advertised. >>> >>> OK for trunk? >>> >>> Paul >> ...snip... >