public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Mikael Morin <morin-mikael@orange.fr>
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 06:52:37 -0700	[thread overview]
Message-ID: <ZEPmpfbQqRhfPhrQ@troutmask.apl.washington.edu> (raw)
In-Reply-To: <311f891f-8fe7-72d3-de38-1b0910aed02c@orange.fr>

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?

-- 
Steve

  reply	other threads:[~2023-04-22 13:52 UTC|newest]

Thread overview: 9+ 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 [this message]
2023-04-22 15:17     ` Mikael Morin
2023-04-22 16:54       ` Steve Kargl
2023-04-22 18:19   ` Harald Anlauf
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=ZEPmpfbQqRhfPhrQ@troutmask.apl.washington.edu \
    --to=sgk@troutmask.apl.washington.edu \
    --cc=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).