From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-29.smtpout.orange.fr [80.12.242.29]) by sourceware.org (Postfix) with ESMTPS id CB4E13858C74 for ; Sat, 22 Apr 2023 18:43:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB4E13858C74 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.15] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id qIDBpWFRobTpSqIDBpPpav; Sat, 22 Apr 2023 20:43:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1682189034; bh=VP44f5iRCvm1NIfnykonAl94rmGAcmBKRj/EtjbA5+g=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Z/vlIqRUTe/MVStS3MdnDVlCam259pRLY7K5a5boSieX92sfuQHi3u4cCqo/ZiWa+ YjA+ityfNfLh6t6wR5WunaWjEFwWUc8AV9f5bMaAOboODOKrjtwtkjJWx6cSQqeWYZ G5Vrp5QNnFizvqxI4pHOWSJgyWQIgUARSUgIQiZ8Em1Zgd56aa2WX9x4ig8rDN5wvP c5BoQV9dcfmo0kZdNTmkXrKxmYwhGYTfEKphvYo8nk8tn4cbzPqq4ePxW+ZZk0g4Br YlRYrb2xmCEXKaF7p44He4U+BRmQ2gQdufsZa1UDps4eftiRiZJ1zkwyXgbAGEpPLF n6QvYtYFIJp+g== X-ME-Helo: [192.168.1.15] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sat, 22 Apr 2023 20:43:54 +0200 X-ME-IP: 86.215.161.51 Message-ID: <60cbf8d5-ad69-c22c-9da2-9c09596e41c6@orange.fr> Date: Sat, 22 Apr 2023 20:43:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500] Content-Language: en-US To: Harald Anlauf , fortran , gcc-patches Cc: kargl@gcc.gnu.org References: <311f891f-8fe7-72d3-de38-1b0910aed02c@orange.fr> <6014ed58-6c37-41f1-5a55-b8c37f30bf40@gmx.de> From: Mikael Morin In-Reply-To: <6014ed58-6c37-41f1-5a55-b8c37f30bf40@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: Le 22/04/2023 à 20:19, Harald Anlauf a écrit : > 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 > Yes, like this. > 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. > Meh! > 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). > OK, let's go with your patch as originally submitted then. Thanks.