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: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Daniel Kraft <d at domob dot eu>
- 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 13:12:38 +0200
- Subject: Re: [Patch, Fortran] PR fortran/44709: Clean up local variables with try-finally
- References: <4C3ECFE5.firstname.lastname@example.org>
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
I don't swear I haven't overlooked anything, but from my point of view,
it looks good.
I'll work on a second patch to remove this (if it works
out) as follow-up. Hopefully this can help the middle-end a little bit
and make the code-structure clearer to it.
Most of the attached patch are more or less mechanical changes (except
the code directly working with gfc_wrapped_block); I used to introduce a
mistake there (which was fortunately caught by a lot of regressions),
but please take a careful look at all those.
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?
I guess there is no way to test this in the testsuite.
Thanks for it,