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 5BB65385770E for ; Sat, 22 Apr 2023 18:19:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5BB65385770E Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pqHq1-0001On-S6 for gcc-patches@gcc.gnu.org; Sat, 22 Apr 2023 20:19:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500] Date: Sat, 22 Apr 2023 20:19:51 +0200 Message-ID: <6014ed58-6c37-41f1-5a55-b8c37f30bf40@gmx.de> References: <311f891f-8fe7-72d3-de38-1b0910aed02c@orange.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US In-Reply-To: <311f891f-8fe7-72d3-de38-1b0910aed02c@orange.fr> Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Message-ID: <20230422181951.0RyfmFpc7SimOzMcc609Ur9oA5A2zFEcrYt8N32yJKk@z> Hi Mikael, Am 22.04.23 um 11:25 schrieb Mikael Morin: > Hello, > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit : >> Dear all, >> >> Fortran 2018 added a clarification that the *result* of a function >> whose result *variable* has the ALLOCATABLE attribute is a *value* >> that itself does not have the ALLOCATABLE attribute. >> >> For those interested: there was a thread on the J3 mailing list >> some time ago (for links see the PR). >> >> The patch which implements a related check was co-authored with >> Steve and regtested by him.  Testcase verified against NAG. >> >> OK for mainline (gcc-14)? >> > Looks good in principle, but I think the real fix should be in the > gfc_expr_attr function, which copies all the attributes (including > allocatable) in the EXPR_FUNCTION case.  How would the testsuite react > if that attribute was cleared there?  Is your patch still needed if > gfc_expr_attr is fixed? you mean like the following? diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc index 00d35a71770..7517efc5414 100644 --- a/gcc/fortran/primary.cc +++ b/gcc/fortran/primary.cc @@ -2775,6 +2775,7 @@ gfc_expr_attr (gfc_expr *e) attr.pointer = CLASS_DATA (sym)->attr.class_pointer; attr.allocatable = CLASS_DATA (sym)->attr.allocatable; } + attr.allocatable = 0; } else if (e->value.function.isym && e->value.function.isym->transformational While this leads to a rejection of the testcase, I see regressions e.g. on allocatable_function_1.f90 and allocatable_function_8.f90 because the function result from a previous invocation does not get freed, and on a subsequent function reference the result variable should always be unallocated. Not sure if the "catch-22" Steve mentions is a good characterization, but a function reference with assignment of the result to an (allocatable) variable, like integer, allocatable :: p p = f() is semantically different from an ordinary assignment to an allocatable variable, where the r.h.s. is an allocatable variable, because the function result variable *must* be deallocated after the assignment, whereas an ordinary variable on the r.h.s must remain unaltered. So I guess it is much less risky to approach the issue by not allowing argument association to an allocatable dummy for an actual argument that is a function reference. (I initially had an even stricter idea to allow only an allocatable *variable* for the actual argument, but did not check the lengthy text on argument association). > Mikael > Harald