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

[Daniel Kraft]

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

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/20080622/1a35fc73/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080622/1a35fc73/attachment-0001.ksh>