This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>, Alessandro Fanfarillo <alessandro dot fanfarillo at gmail dot com>, "Rouson, Damian" <rouson at sandia dot gov>
- Date: Sat, 25 Aug 2012 21:17:26 +0200
- Subject: Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine
- References: <50295E1A.5050108@net-b.de> <50312777.9090007@net-b.de> <5038D6F6.4090601@sfr.fr> <5038ED6B.5010105@net-b.de>
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