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.
