This is the mail archive of the 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: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8

Janus Weil wrote:
unfortunately the current version of the patch ICEs on your test case:

And the ICE happens when creating the finalizer for "universal", which contains the (finalizable) component "type(ref_counter) :: counter" (here, "comp->ts.u.derived" is ref_counter):

      vtab = gfc_get_derived_vtab (comp->ts.u.derived);
      for (c = vtab->ts.u.derived->components; c; c = c->next)
        if (strcmp (c->name, "_final") == 0)
      final_wrap->symtree = c->initializer->symtree;

The problem is that "c->initializer" == NULL. For some reason, all initializer components of _vtab are NULL.

In that code line, one really needs the symtree as one otherwise doesn't have the proper interface of the wrapper. I don't see ad-hoc why there is no symtree. In principle, __final_ref_counter_implementation_Ref_counter exists in ref_counter_implementation.mod as does "(52 '_final' (INTEGER 4 53 0 0 INTEGER ())" where 53 is the id of the wrapper function.

(If one moves all type declarations into the same mode, one no longer runs into this issue.)

I don't quickly see why the "_vtab" lacks the initializer. Janus, do have an idea?

* * *

After moving all derived type decs into the ref_counter module, one gets past that ICE, however, one runs into another ICE as "fini->proc_tree" is NULL in:
if (fini->proc_tree->n.sym->attr.elemental)

It works with the following patch, but I don't know whether it makes sense:

--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -1248,3 +1248,5 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns,
- if (fini->proc_tree->n.sym->attr.elemental)
+ gfc_symbol *fsym;
+ fsym = fini->proc_tree ? fini->proc_tree->n.sym : fini->proc_sym;
+ if (fsym->attr.elemental)
@@ -1269,6 +1271,6 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns,
block->ext.block.case_list->where = gfc_current_locus;
- if (fini->proc_tree->n.sym->attr.dimension)
+ if (fsym->attr.dimension)
= gfc_get_int_expr (gfc_default_integer_kind, NULL,
- fini->proc_tree->n.sym->formal->sym->as->rank);
+ fsym->formal->sym->as->rank);
@@ -1284,3 +1286,3 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns,
block->next->symtree = fini->proc_tree;
- block->next->resolved_sym = fini->proc_tree->n.sym;
+ block->next->resolved_sym = fsym;
block->next->ext.actual = gfc_get_actual_arglist ();

* * *

Finally, one runs into an ICE for conv_parent_component_references. That happens in the finalization wrapper for the derived type "foo" where one accesses "ptr%component%universal%counter", where the latter is part of an abstract type. I haven't investigated why it fails.


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