On 25/08/2012 17:21, Tobias Burnus wrote: > (And nonallocatble, nonpointer > components do not exist.) I missed that indeed.
>> What if only comp's subcomponents are finalizable, the finalization >> wrapper should still be called, shouldn't it? > > Well, that's handled in the "else" branch. There, I walk all > subcomponents. I do not need to walk them in case there is a finalizer > as the called finalization wrapper will handle them. Actually, I don't understand why you walk twice over the subcomponents: in the else branch here and in the finalizer. >> If comp has finalizable subcomponents, it has a finalization wrapper, >> which is (or should be) caught above, so this branch is (or should be) >> unreachable. > > I probably miss something, but I don't see why this branch should be > unreachable. One has: > > if (component is allocatable) > call DEALLOCATE(comp) ! which might invoke finalizers > else if (component itself has a finalizer) > call FINAL_WRAPPER > else > for all nonpointer subcomponents which are allocatables, have > finalizers or have allocatable/finalizable components, call > finalize_component. > end if I expected something like: if (allocatable) call deallocate (comp) else if (finalizer or subcomponents have a finalizer) call FINAL_WRAPPER As said above, I don't understand why you would walk over the components twice >>> >+ else if (comp->ts.type == BT_CLASS && CLASS_DATA (comp) >>> >+ && CLASS_DATA (comp)->attr.allocatable) >>> >+ alloc_comp = true; >> Shouldn't one assume without condition that there are allocatable or >> finalizable subcomponents when there is a polymorphic component? > > Well, we do not deallocate/finalize polymorphic POINTER components. Indeed, then I prefer having !CLASS_DATA(comp)->attr.pointer. >>> >diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c >>> >index 44b1900..4cafefe 100644 >>> >--- a/gcc/fortran/parse.c >>> >+++ b/gcc/fortran/parse.c >>> >@@ -2250,6 +2250,16 @@ endType: >>> > sym->attr.lock_comp = 1; >>> > } >>> > >+ /* Look for finalizers. */ >>> >+ if (c->attr.final_comp >> c->attr.final_comp is never set. >> >> I would like to avoid if possible yet another symbol attribute set in >> three different functions in three different files and used all over the >> place. What about using a function "calculating" the predicate this >> time? > > Maybe, however, one has then to call the function a lot of times: In > generate_finalization_wrapper for the whole type, then for the new added > components, and then for each component in finalize_component. With the > current code, the latter has a complexity of approx. O(n lg n), but one > might be able to improve it a bit by restructuring the code. (On the > other hand, "n" is probably not excessively large.) > If performance is a problem, the function could use the flag as a backend. As long as the field is used and set in a single place, I don't mind. I don't have a strong opinion either, there is already a full bag of flags; one more wouldn't make things dramatically worse. Mikael