public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mikael Morin <morin-mikael@orange.fr>
To: sgk@troutmask.apl.washington.edu
Cc: Harald Anlauf <anlauf@gmx.de>, fortran <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	kargl@gcc.gnu.org
Subject: Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
Date: Sat, 22 Apr 2023 17:17:30 +0200	[thread overview]
Message-ID: <ed005b4a-73a7-3a9b-cdeb-e73f3599902c@orange.fr> (raw)
In-Reply-To: <ZEPmpfbQqRhfPhrQ@troutmask.apl.washington.edu>

Le 22/04/2023 à 15:52, Steve Kargl a écrit :
> On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote:
>>
>> 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 may be correct that something can be done elsewhere.
> I do note that a function result can be allocatable
> (within the funciton body).  The issue only arises when
> argument association is done, which is done where Harald
> and I have the patch.  Do we know that the function will
> be an actual argument associated with an allocatable
> dummy argument when gfc_expr_attr is invoked?
> 
No, there is no context information in gfc_expr_attr, but the result 
should not be dependent on context anyway.

You are probably right that the impact of this bug is limited to the 
case of argument association, not as broad as I thought.  Yet we should 
not keep gfc_expr_attr returning an allocatable attribute for function 
expressions in any case.

  reply	other threads:[~2023-04-22 15:17 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 [this message]
2023-04-22 16:54       ` Steve Kargl
2023-04-22 18:19   ` Harald Anlauf
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=ed005b4a-73a7-3a9b-cdeb-e73f3599902c@orange.fr \
    --to=morin-mikael@orange.fr \
    --cc=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kargl@gcc.gnu.org \
    --cc=sgk@troutmask.apl.washington.edu \
    /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).