Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]

[Mikael Morin <morin-mikael@orange.fr>]

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.