Re: Status of allocatable components

[Erik Edelmann <erik dot edelmann at iki dot fi>]

On Fri, Jun 23, 2006 at 01:58:27AM +0300, Erik Edelmann wrote:
> (someday, I will [...]  write some kind of explanation for it)

Ok, I've begun to write a description of the patch (the latest version
of the patch is found in bugzilla/PR 20541).

When browsing through the patch to write this, I found some things that
looked weird and/or wrong, or just raised questions in other ways.  I
haven't done anything about them yet, but I inserted 'CHECK', 'FIXME'
and 'QUESTION' notes for these things below.


        Erik


---------------------------------------------------
Acronyms used: DTWAC = Derived Type With Allocatable Components

There are lots of small bits and pieces everywhere to allow
declaration of allocatable components, and check that they are
correctly used.  I may write more on this later, but most of it
ought to be pretty straightforward to understand.

There are a few new fields in structs to keep track of
allocatable components:

  * gfortran.h (symbol_attribute) is given a new field
    'alloc_comp'.  It will be set in parse.c (parse_derived) for
    derived types that has allocatable components or
    sub-components.

  * gfortran.h (gfc_component) has a new field 'allocatable'
    with obvious meaning.

One of the most central parts of the patch is the function
trans-array.c (structure_alloc_comps), which recursively
traverses objects of derived type, generating code to deallocate,
nullify or copy allocatable components.  It's used by the
following functions:

  * trans-array.c (nullify_alloc_comp).  Nullifies allocatable
    components, making sure they start their life with allocation
    status defined to 'not allocated'.  Called from:

    - trans-array.c (gfc_trans_deferred_array) for local
      variables on procedure entry.

      FIXME: The comment on this function needs to be changed
      slightly to reflect that it does DTWACs too.

    - trans-array.c (gfc_array_allocate) for newly allocated
      arrays of DTWAC.

      CHECK: Shouldn't we do this for allocated scalars (e.g.
      pointers) too?

    - trans-decl.c (gfc_generate_function_code) for function
      result variables.

    - trans-expr.c (gfc_trans_scalar_assign) in assignments;
      more on that below.

  * trans-array.c (deallocate_alloc_comp).  Deallocate
    allocatable components; used everywhere where variables of
    DTWAC needs deallocation. Called from:

    - trans-expr.c (gfc_trans_scalar_assign) in assignments; more
      on that below.

    - trans-expr.c (gfc_conv_function_call) for arguments that
      are INTENT(OUT) or non-variable scalars (to be deallocated
      before the call), or function results (after the call).

      CHECK: Shouldn't non-variables be deallocated after the
      call too?

    - trans-array.c (gfc_conv_array_parameter) for non-variable
      array arguments.

    - trans-array.c (gfc_trans_deferred_array) for local
      variables on procedure return.

    - trans-stmt.c (gfc_trans_deallocate) for explicitly
      deallocated variables.

  * trans-array.c (copy_alloc_comp).  Used for assignments of
    DTWAC.  Assignments are handled in trans-expr.c
    (gfc_trans_scalar_assign).  The idea is roughly this:

    1. Check that rhs and lhs are not he same variables.
       We need to check this to not harm rhs when operating on
       lhs.

       QUESTION: Could this be done at compile time instead of run
       time?

    2. Deallocate components of lhs.

    3. Do a "plain" assignment (shallow copy of allocatables this
       far).

    4. If rhs is a variable, do a deep copy of allocatable
       components, using trans-array.c (gfc_copy_alloc_comp),
       otherwise, just nullify allocatable components of rhs (to
       avoid damage to lhs when rhs is cleaned up.), and we're
       done.

I'll write something on derived type constructors and MOVE_ALLOC
later.


CHECK: Do we need the rename + move of the function resolve.c
(expr_to_initialize) --> expr.c (gfc_expr_to_initialize)?

FIXME: trans-array.c (copy_alloc_comp, deallocate_alloc_comp,
nullify_alloc_comp) need a gfc_ prefix.