This is the mail archive of the
mailing list for the GNU Fortran project.
PING: Re: [Patch, Fortran] Derived-type finalization, second part split off
- From: Daniel Kraft <d at domob dot eu>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 16 Aug 2008 12:10:57 +0200
- Subject: PING: Re: [Patch, Fortran] Derived-type finalization, second part split off
- References: <489D79D0.email@example.com>
I'm back again, what do you think about this one? And what's about the
message mentioned about temporaries?
Daniel Kraft wrote:
here's a second split-off from the finalization patch after check-in and
remerging the last part; it is roughly everything (remainin after the
last part) except resolve.c changes.
This is somehow the "main part" and includes the logic behind
gfc_finalize_expr, that is, everything except for the integration and
actual *calling* of finalization. This means that this patch for itself
does neither introduce new features nor any risk of breaking something
Maybe we could also include the basic finalization when a symbol goes
out of scope here to get the code actually tested already when this is
checked-in and somewhat working (but for this we would have to remove
the not-yet-implemented message though finalization would be implemented
at best "partially" then). What do you think? From my point of view,
both ways are equally good solutions.
I believe this part of the patch is already quite "stable" and finished,
nothing of the "open issues" affects it; the only point I ask you to
think about is that by checking in this one, we make our lives harder if
we find out that finalization can't possibly be done in the front-end
and we have to move it to trans; but I believe it is highly unlikely
that this should happen, and hope we can resolve the last issues in a
way as I proposed in http://gcc.gnu.org/ml/fortran/2008-08/msg00026.html.
As usual, some XXX comments left in... What do you think about this
patch, ok to commit or should I add some parts of reslve.c as described
above? If I know your decision on how we should handle this part, I'll
of course add a ChangeLog entry.
Regression-tested on x86-32-GNU/Linux with no failures of course, but as
I said above I can't imagine how this patch should break something at
PS: From today evening, I'll be off until coming Friday, possibly late
at night; I'm doing a mountain-trip near the Großglockner (well, what do
Austrians do in the summer when there's no snow to ski?). So take your
Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
To go: Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou