public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/37336] Fortran 2003: Finish derived-type finalization
Date: Mon, 07 May 2012 10:20:00 -0000	[thread overview]
Message-ID: <bug-37336-4-Wskw1OZTGe@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-37336-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
         AssignedTo|domob at gcc dot gnu.org    |unassigned at gcc dot
                   |                            |gnu.org

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-07 10:09:52 UTC ---
Regarding FINAL but also normal deallocation - including polymorphic
deallocation: Variables with the SAVE attribute shouldn't be automatically
deallocated. That includes variables of the main program which are implicitly
SAVE!

Currently, gfortran deallocates them automatically, which is nice for
"valgrind" results - and not detectable by the program.

However, with FINAL - but also for allocatable coarrays (except
-fcoarray=single) - one cannot do it. Coarrays might be still accessed from
other images while FINAL shouldn't be called - thus a simple 'print *,
"gotcha"' in FINAL would be able to detect this.

Note: A normal freeing for noncoarrays, including polymorphic freeing, would be
still possible if one simply skips all FINAL calls. At least I do not see how
that should be detectable from within the program.


  parent reply	other threads:[~2012-05-07 10:11 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-37336-4@http.gcc.gnu.org/bugzilla/>
2010-10-26  7:46 ` burnus at gcc dot gnu.org
2010-12-02  4:35 ` damian at rouson dot net
2010-12-27  2:04 ` dfranke at gcc dot gnu.org
2012-03-15 17:41 ` w6ws at earthlink dot net
2012-03-18 15:53 ` tkoenig at gcc dot gnu.org
2012-05-07 10:20 ` burnus at gcc dot gnu.org [this message]
2012-09-03  6:37 ` burnus at gcc dot gnu.org
2012-09-22 17:08 ` burnus at gcc dot gnu.org
2012-10-26 16:47 ` janus at gcc dot gnu.org
2012-11-27 20:04 ` burnus at gcc dot gnu.org
2012-12-03  8:55 ` burnus at gcc dot gnu.org
2012-12-03  9:01 ` janus at gcc dot gnu.org
2012-12-03 21:14 ` burnus at gcc dot gnu.org
2012-12-05  8:54 ` janus at gcc dot gnu.org
2013-05-28 18:31 ` burnus at gcc dot gnu.org
2013-05-28 18:33 ` burnus at gcc dot gnu.org
2013-05-29 13:23 ` burnus at gcc dot gnu.org
2013-05-29 13:26 ` burnus at gcc dot gnu.org
2013-06-04 10:21 ` burnus at gcc dot gnu.org
2013-06-04 10:27 ` burnus at gcc dot gnu.org
2013-06-08 12:28 ` burnus at gcc dot gnu.org
2013-06-21 21:53 ` burnus at gcc dot gnu.org
2013-07-22 11:01 ` janus at gcc dot gnu.org
2013-07-31 20:43 ` janus at gcc dot gnu.org
2014-01-12 11:12 ` [Bug fortran/37336] [F03] " janus at gcc dot gnu.org
2014-02-08 21:36 ` janus at gcc dot gnu.org
2014-03-15 12:14 ` janus at gcc dot gnu.org
2014-03-18 22:23 ` janus at gcc dot gnu.org
2014-12-15 11:50 ` janus at gcc dot gnu.org
2015-02-15 16:03 ` dominiq at lps dot ens.fr
2015-02-15 16:58 ` sourcery at rouson dot net
2015-09-03 16:08 ` dominiq at lps dot ens.fr
2015-09-03 20:35 ` fxcoudert at gcc dot gnu.org
2015-09-07  9:54 ` ian_harvey at bigpond dot com
2015-09-25 20:35 ` mikael at gcc dot gnu.org
2020-06-01 18:52 ` tkoenig at gcc dot gnu.org
2020-06-14 21:27 ` tkoenig at gcc dot gnu.org
2020-07-13 20:00 ` dominiq at lps dot ens.fr
2021-11-09 20:57 ` cvs-commit at gcc dot gnu.org
2022-02-01 14:31 ` pault at gcc dot gnu.org
2022-02-03 13:13 ` pault at gcc dot gnu.org
2023-03-18  7:56 ` cvs-commit at gcc dot gnu.org
2023-03-18 12:21 ` pault at gcc dot gnu.org
2023-03-18 12:23 ` pault at gcc dot gnu.org
2023-03-18 15:22 ` pault at gcc dot gnu.org
2023-03-18 15:25 ` pault at gcc dot gnu.org
2023-03-18 15:46 ` pault at gcc dot gnu.org
2023-03-18 15:49 ` pault at gcc dot gnu.org
2023-03-18 15:53 ` pault at gcc dot gnu.org
2023-03-18 16:00 ` pault at gcc dot gnu.org
2023-03-18 16:19 ` pault at gcc dot gnu.org
2023-03-18 17:25 ` pault at gcc dot gnu.org
2023-03-18 17:28 ` pault at gcc dot gnu.org
2023-03-18 17:31 ` pault at gcc dot gnu.org
2023-03-18 17:34 ` pault at gcc dot gnu.org
2023-03-18 17:35 ` pault at gcc dot gnu.org
2023-04-14 13:59 ` pault at gcc dot gnu.org
2023-04-14 14:11 ` pault at gcc dot gnu.org
2023-04-14 14:13 ` pault at gcc dot gnu.org
2023-05-22  6:40 ` trnka at scm dot com
2023-09-29 12:57 ` cvs-commit at gcc dot gnu.org
2023-09-29 13:13 ` cvs-commit at gcc dot gnu.org
2023-10-04  7:26 ` cvs-commit at gcc dot gnu.org
2023-10-04  8:22 ` cvs-commit at gcc dot gnu.org
2023-10-04  8:24 ` pault at gcc dot gnu.org
2023-11-28 15:39 ` andrewjenner at gcc dot gnu.org
2024-04-08 11:14 ` vterzi1996 at gmail dot com
2008-09-02 17:00 [Bug fortran/37336] New: Fortran 2003: " domob at gcc dot gnu dot org
2008-09-02 17:00 ` [Bug fortran/37336] " domob at gcc dot gnu dot org
2008-09-02 17:06 ` domob at gcc dot gnu dot org
2008-09-02 17:09 ` domob at gcc dot gnu dot org
2010-06-23 14:14 ` burnus at gcc dot gnu dot org
2010-06-23 14:22 ` burnus at gcc dot gnu dot org

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-37336-4-Wskw1OZTGe@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).