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


>> 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)
>           break;
> ...
>       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?

yes, for some reason the initializers for components of a vtype are
not written to the module file. I don't remember exactly why it was
necessary, but the following patchlet fixes it:

Index: gcc/fortran/module.c
--- gcc/fortran/module.c	(revision 192767)
+++ gcc/fortran/module.c	(working copy)
@@ -2597,8 +2597,7 @@ mio_component (gfc_component *c, int vtype)
     c->attr.class_ok = 1;
   c->attr.access = MIO_NAME (gfc_access) (c->attr.access, access_types);

-  if (!vtype)
-    mio_expr (&c->initializer);
+  mio_expr (&c->initializer);

   if (c->attr.proc_pointer)

This gets me past the ICE ...

> 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)

... somehow I don't see this one ...

> 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.

... and I also end up with this.

I'll regtest the attached new version of the patch tonight, hoping to
find out where the module tweak was necessary.


Attachment: final-2012-10-24_v3.diff
Description: Binary data

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