From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id B6B9B385842B for ; Mon, 8 Jan 2024 21:53:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B6B9B385842B Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B6B9B385842B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704750811; cv=none; b=cnZqFW9x3sr6WgR0ilZay1KtdcOqTdoFHJGfxGLxLLt+83FTsRjt1RWuywcUl9zT4/gKMw8EqoOjhV20o8pxrM08OaJp7q02je0dwOeUU+DZ0ksrQYsqaYZYk09bcsiSkx4h6Js+YDIEdLxYAP9sKQkD0Q5PCuTUNSX5uxMZbEM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704750811; c=relaxed/simple; bh=oRddYcioCdF/Ns9xKA+5ZdF4kf5BF1sBjK9LFx6xa+8=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=dq3jlJ1RwRdl1jH+fi/G6UoK61nqJxoi3tY2gFV82AKSChouHIFA6XZ8DRHaWSGh0UKTx1o22DblPemKd9pjU4id0ZzWuQ4YWdPNLOVGDEUBu0aji3HH7A1pgxjvIq+7p0r25LPZq01RsoQENC04x9UdHBOJ8UcBusKeMzNXPE0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rMxYm-0008dd-IM for gcc-patches@gcc.gnu.org; Mon, 08 Jan 2024 22:53:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() ) Date: Mon, 8 Jan 2024 22:53:21 +0100 Message-ID: <674cfbf0-a95d-4433-a025-29e78dc0bcef@gmx.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20240108215321.W0Av3aXu25LWLqk8kzr4oibiV3E6w1yVe3tebQ7_GsY@z> 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 = foo() call prt (x) deallocate (x) ! up to here no memleak... associate (var => foo()) call prt (var) end associate contains function foo() result(res) class(*), allocatable :: res(:) res = [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 its > 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 type > but, instead, a class function. If it were not for this, the patch would > 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 variants 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 > > Fortran: Fix class/derived type function associate selectors [PR87477] > > 2024-01-06 Paul Thomas > > gcc/fortran > PR fortran/87477 > PR fortran/89645 > PR fortran/99065 > * class.cc (gfc_change_class): New function needed for > associate names, when rank changes or a derived type is > produced by resolution > * dump-parse-tree.cc (show_code_node): Make output for SELECT > TYPE more comprehensible. > * gfortran.h : Add 'gfc_association_list' to structure > 'gfc_association_list'. Add prototypes for > 'gfc_find_derived_types', 'gfc_fixup_inferred_type_refs' and > 'gfc_change_class'. Add macro IS_INFERRED_TYPE. > * match.cc (copy_ts_from_selector_to_associate): Add bolean arg > 'select_type' with default false. If this is a select type name > and the selector is a inferred type, build the class type and > apply it to the associate name. > (build_associate_name): Pass true to 'select_type' in call to > previous. > * parse.cc (parse_associate): If the selector is a inferred type > the associate name is too. Make sure that function selector > class and rank, if known, are passed to the associate name. If > a function result exists, pass its typespec to the associate > name. > * primary.cc (gfc_match_varspec): If a scalar derived type > select type temporary has an array reference, match the array > reference, treating this in the same way as an equivalence > member. If this is a inferred type with a component reference, > call 'gfc_find_derived_types' to find a suitable derived type. > * resolve.cc (resolve_variable): Call new function below. > (gfc_fixup_inferred_type_refs): New function to ensure that the > expression references for a inferred type are consistent with > the now fixed up selector. > (resolve_assoc_var): Ensure that derived type or class function > selectors transmit the correct arrayspec to the associate name. > (resolve_select_type): If the selector is an associate name of > inferred type and has no component references, the associate > name should have its typespec. > * symbol.cc (gfc_set_default_type): If an associate name with > unknown type has a selector expression, try resolving the expr. > (find_derived_types, gfc_find_derived_types): New functions > that search for a derived type with a given name. > * trans-expr.cc (gfc_conv_variable): Some inferred type exprs > escape resolution so call 'gfc_fixup_inferred_type_refs'. > * trans-stmt.cc (trans_associate_var): Tidy up expression for > 'class_target'. Correctly handle selectors that are class array > references, passed as derived types. > > gcc/testsuite/ > PR fortran/87477 > PR fortran/89645 > PR fortran/99065 > * gfortran.dg/associate_64.f90 : New test >