This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi Daniel,

using your patch, I get the following crash. I did not quickly see
whether finalize_derived_components is supposed to be called or not. In
any case the testcases do not have finalizers.

I don't know whether this is related to the intrinsic problem you
mentioned in http://gcc.gnu.org/ml/fortran/2008-06/msg00254.html
or whether it is because I wronly applied the patch at
http://gcc.gnu.org/ml/fortran/2008-07/msg00020.html

 * * *

gfortran.dg/alloc_comp_assign_6.f90:25: internal compiler error:
Segmentation fault

The problem is that for the 11th call to finalize_derived_components:

3695      gcc_assert (expr->expr_type == EXPR_VARIABLE);
(gdb)
3698      as = expr->symtree->n.sym->as;
(gdb) p expr->expr_type
$1 = EXPR_VARIABLE
(gdb) p expr->symtree
$2 = (gfc_symtree *) 0x0

Line 25:

24     allocate(var%chars(length))
25     forall(i_char = 1:length)
26       var%chars(i_char) = exp(i_char:i_char)
27    end forall
28  end subroutine op_assign_VS_CH


 * * *

Same problem for:

gfortran.dg/interface_assignment_2.f90:21: internal compiler error:
Segmentation fault
(9th "cont")

Line 21:

18  elemental subroutine op_assign_VS_CH (var, expr)
19    type(varying_string), intent(out) :: var
20    character(LEN=*), intent(in)      :: expr
21    var = var_str(expr)
22  end subroutine op_assign_VS_CH


 * * *

Some other items:

+  /* Now the type is finalizable iff it has finalizer procedures.  */

s/iff/if/

+  ! XXX: Should we also include a test with assumed size?
It cannot harm, however, they simply should not be finalized thus I'm
not sure whether it is needed.

 * * *

+    ! XXX: Why compile error otherwise?
+    !TYPE(no_t), POINTER :: ptr

This is a bug. Initially no empty derived types were allowed
and thus the check (resolve.c)
      if (c->ts.type == BT_DERIVED && c->pointer
          && c->ts.derived->components == NULL)
        {
          gfc_error ("The pointer component '%s' of '%s' at %L is a type "
                     "that has not been declared", c->name, sym->name,
was OK. That part was missing when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33221
was fixed. Thanks for spotting it.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]