Finalization and automatic deallocation

Paul Richard Thomas paul.richard.thomas@gmail.com
Sun Jun 15 17:48:00 GMT 2008


I am sorry to have left you, Janus and Tobias in the lurch these last
weeks - I have just returned from a trip.  I'll try to catch up over
the next few days.

On Sun, Jun 15, 2008 at 10:37 AM, Daniel Kraft <domob1812@gmail.com> wrote:
> Daniel Kraft wrote:
>
>> What I'm thinking of in more detail:  Port the gfc_finalize_expr & friends
>> to working on trees together with gfc_symbol's representing their original
>> derived-type rather than gfc_expr's so those can be used from trans; if this
>> is ok, I'm also thinking of adding a new gfortran-internal statement-type

The allocatable components finalization wound up in trans-array.c
because it would up to be so much more convenient there.  If I had
thought about nested finalizable derived types, I might well have
suggested following the same route.

>> EXEC_FINALIZE that can be added to the tree during resolution where
>> appropriate so we still can implement some things in resolution when they
>> are easier there.  Those statements will then be converted to GIMPLE during
>> trans using the ported finalization-method.
>
> Just another thought:  What do you think about moving auto-deallocation
> logic from trans to resolution?  I think it should be very much the same
> like finalization to generate EXEC_DEALLOCATE statements there at the needed
> places.  And doing so could allow us to keep finalization in resolution
> phase and still have no duplication.  It could even be easier to do
> auto-deallocation there.

I think that you'll have to explain what you mean here.  Maybe I'm
tired:) but I don't understand what you are proposing.
>
> After some more thoughts I think that finalization is really done easier in
> resolution because much information needed (beyond the derived-type an
> expression is of) will not (or I don't think it will) available in trans,
> like expression rank (or is it available from a raw tree).
>
> If you think this could be a good solution, I'll try to finish finalization
> in resolution with possible duplication regarding auto-deallocation first
> (the patch is already growing big I think), and in the next step I can try
> to merge auto-deallocation from trans into my finalization logic during
> resolution.

The information that you talk about is not exclusive to resolution -
take a look at structure_alloc_comps and the subsequent primitives for
the API.  Erik and I worked hard to make that work.  I had hoped that
doing the business in resolve.c might be more transparent.

>
> If I find time, I'll try to finish finalization as described above; but I'd
> be happy to hear your comments as I'm not really aware of most the details
> of gfortran...

I'm not exactly sure that any of us are anymore!  I have become
convinced that we must start breaking out the F03/F08 parts into new
source files to simplify the job of keeping track of things.

Anyway, I'll try to devote some time to this over the next days -
watch this space.

Thanks for your and Janus' efforts on these new features.

Cheers

Paul



More information about the Fortran mailing list