This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR fortran/44709: Clean up local variables with try-finally
- From: Daniel Kraft <d at domob dot eu>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 15 Jul 2010 14:30:44 +0200
- Subject: Re: [Patch, Fortran] PR fortran/44709: Clean up local variables with try-finally
- References: <4C3ECFE5.firstname.lastname@example.org> <4C3EED26.email@example.com>
Mikael Morin wrote:
Le 15.07.2010 11:07, Daniel Kraft a écrit :
Hi all,The testsuite will tell ;-)
the attached patch does what I wrote about in
http://gcc.gnu.org/ml/fortran/2010-07/msg00058.html. Briefly, I modified
gfc_trans_deferred_vars and its callees such that init and cleanup code
(like memory allocation / deallocation) is collected seperately rather
than wrapped around the function body directly; this is then used to do
the clean-up with a try-finally middle-end expression, so that all exits
safely do the cleanup automagically. Which fixes the wrong-code /
memory-leak part of PR 44709.
Currently, multiple returns from procedures are handled via a jump to a
label at the end of the function, from which on the cleanup was done
before (in order to work around the problem in the PR for BLOCKs). I
think that this may no longer be needed in fact now (am I right? Or is
there another reason why we want only a single exit point from all
yes, I'll just try to do that.
I guess there is no way to test this in the testsuite.
No regressions on GNU/Linux-x86-32, and additionally valgrind shows no
longer any memory leaks for code like that in the PR (and the tree-dump
also looks fine). This was with SVN trunk some days ago, though, so I'm
at the moment building and testing with a fresh update.
Ok for trunk if no failures with that, either?
FINAL would be one, but unfortunately not yet... ;)
Committed as rev. 162219.
Thanks for the fast review!
To go: Hea-Kni-Mon-Pri