Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8

[Tobias Burnus <burnus at net-b dot de>]

Hi all,

Janus Weil wrote:
> > > 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 have a fix, but I do not understand the current code. In the 
finalization subroutine, "counter" of type "ref_counter" should be 
finalized. Hence, the generated code calls 
"__final_foo_implementation_Ref_counter" with the argument:

 ptr%component%universal%counter

For some reason, that's incompatible with how gfc_conv_variable works. 
For "ptr%component" everything is fine. One then has as "ref" the 
component ref to "universal":

        case REF_COMPONENT:
          if (ref->u.c.sym->attr.extension)
            conv_parent_component_references (se, ref);
          gfc_conv_component_ref (se, ref);

As ref already is the "universal", the search for c->name "universal" in 
dt->components (with "dt = ref->u.c.sym") fails. Hence, a new ref 
("parent") to "universal" is generated:
  conv_parent_component_references (se, &parent);

However, after conv_parent_component_references returned, the next line 
again tries to add a ref to parent, which unsurprisingly fails.


I have no idea whether I did something different in the wrapper or 
whether it can also occur in general, however, it is fixed by the 
following patch.

 * * *

Janus patch plus this one is sufficient to compile and run Damian's 
test, but it shows "fail". num_currently_allocated() returns 3 at the 
end - instead of 0. Comparing the result with the one I get with 
crayftn, I see missing lines of the type:

 finalize_ref_counter: start
 release: start
 release: end
 finalize_ref_counter: end

(Instead one has "finalize_ref_counter: start"/"finalize_ref_counter: end".)

Those seem to be due to the missing type-bound defined assignment, where 
Paul's patch is pending.

Additionally, "call_cpp_delte_foo" is never called. That one is called 
by release, which in turn seems to be require (cf. above) Paul's patch 
for PR46897. Hence, it is difficult to really see whether the code works 
correctly or not.

Tobias

PS: I just saw that some of the calls to the wrapper are still 
incomplete. The finalization wrapper takes a "bool coarray" argument and 
while some calls pass "false" (or true) as second argument in the call 
to the wrapper, others don't.

The coarray argument is used - or will be used (I didn't look at the 
patch) - to decide whether to finalize the coarray component. For 
intrinsic assignment, it may not be reallocated (and hence finalized) 
while for DEALLOCATE of the parent or for going out of scope, it has to 
be finalized.

I am not completely sure whether one needs that flag, but presumably one 
does. (I only know for sure after fixing the COMPONENT issue, which we 
currently have deferred.)
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index b0bd7f5..4c7ff0a 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1510,6 +1519,9 @@ conv_parent_component_references (gfc_se * se, gfc_ref * ref)
   dt = ref->u.c.sym;
   c = ref->u.c.component;
 
+  if (c->name == dt->name)
+    return;
+
   /* Return if the component is not in the parent type.  */
   for (cmp = dt->components; cmp; cmp = cmp->next)
     if (strcmp (c->name, cmp->name) == 0)