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: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8


Hi,

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

... but yields a good number of testsuite regressions (mostly related
to __def_init, I think). So I have settled with the following version
(which treats only the initializer of _final, but not of the other
vtype components):


Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c	(revision 192767)
+++ gcc/fortran/module.c	(working copy)
@@ -2597,7 +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)
+  if (!vtype || strcmp (c->name, "_final") == 0)
     mio_expr (&c->initializer);

   if (c->attr.proc_pointer)


The updated patch in the attachment now only fails on:

FAIL: gfortran.dg/class_array_14.f90  -O0  execution test


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

The exact signature is:

internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1483


Here is a reduced test case which triggers this:


module ref_counter_implementation
  type ref_counter
  contains
    final :: finalize_ref_counter
  end type
contains
  subroutine finalize_ref_counter (this)
    type(ref_counter) :: this
  end subroutine
end module

module foo_implementation
  use ref_counter_implementation
  implicit none
  type :: hermetic
  end type
  type, extends(hermetic) :: universal
    type(ref_counter) :: counter
  end type
  type, extends(universal) :: foo_component
  end type
  type :: foo
    type(foo_component) :: component
  end type
contains
  subroutine call_cpp_delete_foo(this)
    class(foo) :: this
  end subroutine
end module


I currently don't see why it fails, and I think I will first try to
make some progress on class_array_14.f90 (i.e. PR 54618).

Cheers,
Janus

Attachment: final-2012-10-25.diff
Description: Binary data


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