From: Harald Anlauf <anlauf@gmx.de>
To: Mikael Morin <morin-mikael@orange.fr>,
fortran <fortran@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Cc: kargl@gcc.gnu.org
Subject: Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
Date: Sat, 22 Apr 2023 20:19:51 +0200 [thread overview]
Message-ID: <6014ed58-6c37-41f1-5a55-b8c37f30bf40@gmx.de> (raw)
In-Reply-To: <311f891f-8fe7-72d3-de38-1b0910aed02c@orange.fr>
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
next prev parent reply other threads:[~2023-04-22 18:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 20:01 Harald Anlauf
2023-04-22 9:25 ` Mikael Morin
2023-04-22 13:52 ` Steve Kargl
2023-04-22 15:17 ` Mikael Morin
2023-04-22 16:54 ` Steve Kargl
2023-04-22 18:19 ` Harald Anlauf [this message]
2023-04-22 18:43 ` Mikael Morin
2023-04-24 18:31 ` Steve Kargl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6014ed58-6c37-41f1-5a55-b8c37f30bf40@gmx.de \
--to=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=kargl@gcc.gnu.org \
--cc=morin-mikael@orange.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).