public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
@ 2010-11-03 16:31 ` jb at gcc dot gnu.org
2013-12-21 20:36 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jb at gcc dot gnu.org @ 2010-11-03 16:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jb at gcc dot gnu.org
--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-11-03 16:31:08 UTC ---
In runtime/main.c we have
static void __attribute__((destructor))
cleanup (void)
{
close_units ();
if (please_free_exe_path_when_done)
free ((char *) exe_path);
}
As this function is marked with the destructor attribute, it will be called
when the library is unloaded during program shutdown.
It might make sense to add
fbuf_flush(u);
sflush(u);
to some appropriate place in unit.c(close_unit_1). That is, make sure to flush
the unit as part of the closing procedure.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
2010-11-03 16:31 ` [Bug fortran/43849] Add _gfortran_finalize function to close down the library jb at gcc dot gnu.org
@ 2013-12-21 20:36 ` dominiq at lps dot ens.fr
2015-08-24 20:05 ` [Bug libfortran/43849] " fxcoudert at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-12-21 20:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2013-12-21
Ever confirmed|0 |1
--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is this PR still pertinent (2013-12-21)?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
2010-11-03 16:31 ` [Bug fortran/43849] Add _gfortran_finalize function to close down the library jb at gcc dot gnu.org
2013-12-21 20:36 ` dominiq at lps dot ens.fr
@ 2015-08-24 20:05 ` fxcoudert at gcc dot gnu.org
2015-09-03 16:05 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-24 20:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
--- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #0)
> Currently, _gfortran_abort calls:
> close_units ();
> Additionally, one should call:
> flush_all_units ();
close_units() actually flushes all units when closing then.
(In reply to Janne Blomqvist from comment #3)
> cleanup() in runtime/main.c is marked with the destructor attribute, it will be
> called when the library is unloaded during program shutdown.
>
> It might make sense to add
>
> fbuf_flush(u);
> sflush(u);
Same reply: when we close units, we do flush them. This is already ensured in
the close functions of io/unix.c.
So, to summarize: we already have a finalization function, cleanup(). Should we
export it? I am not so sure, unless we have a real use case.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2015-08-24 20:05 ` [Bug libfortran/43849] " fxcoudert at gcc dot gnu.org
@ 2015-09-03 16:05 ` dominiq at lps dot ens.fr
2015-09-03 20:28 ` jb at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-03 16:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |37336
--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> So, to summarize: we already have a finalization function, cleanup().
> Should we export it? I am not so sure, unless we have a real use case.
Could someone answer the question?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2015-09-03 16:05 ` dominiq at lps dot ens.fr
@ 2015-09-03 20:28 ` jb at gcc dot gnu.org
2015-09-03 20:31 ` dominiq at lps dot ens.fr
2015-09-03 20:35 ` fxcoudert at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: jb at gcc dot gnu.org @ 2015-09-03 20:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #7)
> > So, to summarize: we already have a finalization function, cleanup().
> > Should we export it? I am not so sure, unless we have a real use case.
>
> Could someone answer the question?
IMHO, no there isn't a real use case for exporting the cleanup() function.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2015-09-03 20:28 ` jb at gcc dot gnu.org
@ 2015-09-03 20:31 ` dominiq at lps dot ens.fr
2015-09-03 20:35 ` fxcoudert at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-03 20:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> IMHO, no there isn't a real use case for exporting the cleanup() function.
Does it mean that this PR could be closed? FIXED or WONTFIX?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/43849] Add _gfortran_finalize function to close down the library
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2015-09-03 20:31 ` dominiq at lps dot ens.fr
@ 2015-09-03 20:35 ` fxcoudert at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-09-03 20:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #10 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Closing as WONTFIX for now. If a real use case (for example co-open array
related) is raised, we can export cleanup() in the future.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-09-03 20:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-43849-4@http.gcc.gnu.org/bugzilla/>
2010-11-03 16:31 ` [Bug fortran/43849] Add _gfortran_finalize function to close down the library jb at gcc dot gnu.org
2013-12-21 20:36 ` dominiq at lps dot ens.fr
2015-08-24 20:05 ` [Bug libfortran/43849] " fxcoudert at gcc dot gnu.org
2015-09-03 16:05 ` dominiq at lps dot ens.fr
2015-09-03 20:28 ` jb at gcc dot gnu.org
2015-09-03 20:31 ` dominiq at lps dot ens.fr
2015-09-03 20:35 ` fxcoudert at gcc dot gnu.org
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).