[PATCH, Fortran] Derived type finalization: Already somewhat useable...

[Daniel Kraft]

Daniel Kraft wrote:
> Hi,
> 
> here's what I would call a "first official patch" for derived type
> finalization, despite the numerous ones already cycled to the list :D

A small update (one-liner to exclude result-variables from
find_finalizable_symbols in resolve.c) that fixes the problem with
symtree==NULL discussed upthread (that is, it avoids it by not trying to
finalize result variables).  With this one, the whole testsuite succeeds
for me on GNU/Linux-x86-32 without the two failures in the new tests
themselves and parameter_array_init_4.f90 which seems to be not my fault.

I'm not sure if the fix like this is good, as I'm not sure if
gfc_lval_expr_from_sym should be able to generate correct gfc_expr
structures even for result-variables.  Whether there's another problem
lying deeper to be fixed or we should simply exclude result-variables
from being finalized I leave up to you.

Thanks,
Daniel

> It's already gotten rather big I'd say, but also already works for most
> cases and events.  Maybe we could work this out fully and get it checked
> in even despite the not-yet-implemented special cases discuessed below?
> 
> Ok, about my patch:  As usual with me, I've "some" XXX marks in it at
> places that I wanted to remember, partly for me to look at later and
> partly because of questions.  I hope to resolve all of those before
> check-in, so no XXX will be checked in ;).
> 
> General points I'm unsure about and would like to get extra-detailed 
> review:
> 
> * Because of my code generation, I'm at multiple places building
> gfc_code/gfc_expr nodes (and others).  I'm nearly nowhere sure if I did
> this correctly (it just works), i.e. I filled in all members I need to,
> didn't fill in members I shouldn't, use invalid intialization values,
> and so on.
> 
> * For the same reason, at a lot of places I'm using gfc_expr nodes
> somewhere in a built expression/statement.  Most of the time I believe I
> did wrap it into gfc_copy_expr because I intuitively think this is
> correct, but please check if I somewhere copy an expression that should
> not be copied and somewhere don't copy one that should be.
> 
> * build_intrinsic_call is surely absolutelly ugly and wrong, I'd love to
> get correction here as to how to do this the right way without this
> symbol stuff, which seems to be causing some testsuite failures (for
> instance, use_allocated_1.f90).  The current version just works for me
> most of the time so I could use it for testing the other things based on 
> it.
> 
> My patch currently does not handle finalization of entities returned by
> a function or structure constructor after they have been used as I think
> that one could be difficult to do (but I haven't done much research yet,
> it could also be easy; we'll see in the future), and the similar clause
> about specification expressions.
> 
> As I pointed out on the list before, finalization of entities "when they
> are deallocated" caused some extra-headache because of automatic
> deallocation; I had to effectively duplicate the logic there to insert
> finalization code each time before automatic deallocation would happen.
>    On the other hand, finalization and automatic deallocation have much
> in common, so it wasn't that bad.  I even propose we could remove the
> implementation of auto-deallocation in trans and reuse the finalization
> logic (only insert an additional EXEC_DEALLOCATE node at the place
> marked in gfc_finalize_expr) once this patch and logic is working
> properly.  But this decision has time until finalization is done.
> 
> Regarding the auto-deallocation, I also came about some things in the
> standard that are unclear to me, see my current thread at
> comp.lang.fortran.  For instance, according to my interpretation,
> allocated ALLOCATABLE components of derived types should be
> auto-deallocated when their parent type is *deallocated* (as pointer
> target or being ALLOCATABLE itself), but I can't see why they are
> auto-deallocated when a static entity of the parent derived type goes
> out of scope.  gfortran trunk *does* auto-deallocate such entities,
> which seems reasonable to me but I can't read from the standard.
> 
> The standard also requires the implementation to auto-deallocate
> ALLOCATABLE components in derived type function results, like the
> requirement of those being finalized.  This is currently not done by
> gforran, too (as I pointed out, that could be difficult).  That's the
> reason for why I think we could try to check the current patch in before
> working on that issue, as we could do the finalization *and*
> auto-deallocation in this case together in a new patch.
> 
> I did implement the finalization in every case the way I read the
> standard, which means that for instance with the static entity thing
> finalization and auto-deallocation does not match as should be (gfortran
> will deallocate the ALLOCATABLE components while they will not be
> finalized first), but please clarify to me what of my understanding of
> the standard is wrong, so I can adapt my implementation accordingly.
> 
> The patch as attached succeeds most of the testsuite on
> GNU/Linux-x86-32, and I believe the old tests that fail are all due to
> the build_intrinsic_call problem talked about above while the new
> failures are due to lack of this temporary-result-finalization.  For
> checking this patch in we could take those checks out of their current
> place and put them in new tests later when working on the new patch.
> 
> This got rather long, sorry...  But I hope you've not been scared away.
> 
> Daniel
> 


-- 
Done:     Bar-Sam-Val-Wiz, Dwa-Elf-Hum-Orc, Cha-Law, Fem-Mal
Underway: Ran-Gno-Neu-Fem
To go:    Arc-Cav-Hea-Kni-Mon-Pri-Rog-Tou

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.changelog
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080712/169bdb9c/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080712/169bdb9c/attachment-0001.ksh>