This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH, Fortran] Derived type finalization: Already somewhat useable...
- From: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- To: fortran at gcc dot gnu dot org
- Date: Wed, 9 Jul 2008 23:12:29 +0200
- Subject: 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