public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/41453] use INTENT(out) for optimization
Date: Sun, 25 Sep 2022 20:32:05 +0000	[thread overview]
Message-ID: <bug-41453-4-5lO8KZvsup@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-41453-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453

--- Comment #16 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #15)
> Status update:

A lot of progress :-)

> (In reply to Thomas Koenig from comment #5)
> > Still missing: To clobber
> > 
> > - variables passed by reference to the caller
> > - saved variables
> > - associated variables (there are passed as pointers to
> >   the associate blocsk)
> These have been done now.
> 
> Still missing: pointer or allocatable dummy.
> Seems doable, probably a low hanging fruit.

For an allocatable dummy, we have to deallocate on intent(out)
anyway, and we do this on the caller's side, so we should not clobber. 
For pointers, it could be an advantage.

> > - intent(out) variables on entry to the procedure.
> This remains to do.

Again, sounds doable


> Another case that could be handled is the case of arrays:
> when the full array is passed as argument, and it is contiguous, and maybe
> some other condition, we can clobber its decl.  The hard part is the "maybe
> some other condition".

Not sure what that other condition could be.  If we have a full array ref, as
per gfc_full_array_ref_p, and we pass this to an intent(out) argument,
then that should be enough.

> Not sure it's worth keeping this PR open.
> Surely the initial test works as expected, and has been working for a long
> time.

There are still a few open points in relation to this.  I would be in
favor of keeping this open (to not lose the discussion) until we have
them all fixed, or decide not to fix some or all of them.

      parent reply	other threads:[~2022-09-25 20:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-41453-4@http.gcc.gnu.org/bugzilla/>
2012-06-29 14:26 ` [Bug middle-end/41453] " Joost.VandeVondele at mat dot ethz.ch
2013-03-29  9:04 ` Joost.VandeVondele at mat dot ethz.ch
2022-08-25 19:31 ` anlauf at gcc dot gnu.org
2022-08-25 19:58 ` [Bug fortran/41453] " anlauf at gcc dot gnu.org
2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org
2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org
2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org
2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org
2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org
2022-09-25 16:42 ` mikael at gcc dot gnu.org
2022-09-25 20:32 ` tkoenig at gcc dot gnu.org [this message]

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=bug-41453-4-5lO8KZvsup@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).