Finalization queries/issues

Finalization queries/issues

This is backwards -
I started at the end, realised I had no idea what I was doing, and worked
backwards to the simplest cases. Might
be some repetition in examples as a result.

Everything here with
/check:all /warn:all /standard-semantics (plus whatever the defaults are for a
fortran console project under VS 2005) for IA32.

Explicit
de-allocation of a scalar or array derived types seems to invoke the
finalisation routines as I expect ("expect" in the sense that it didn't surprise me, not in the sense that I've engaged in detailed study and actually have a clue what should happen).
Finalization of local variables when they go out of scope seems a bit
hit and miss, particular if there's a polymorphic thing being finalized, in which case there's evidently a problem.

local-final.f90

local-final-array.f90

When I started
looking at finalization and type extension trees I got an ICE. Well, at least I know for sure that's not supposed to happen!

ice-20110405.f90

Otherwise, for local
variables going out of scope results are similar to the local-final case above
(polymorphic variables cause grief).

poly-final.f90

Before I got to the
stuff above I was looking at trying to jam some deallocation into the
finalization to avoid a memory leak. My
first attempt showed that explicit deallocation of the polymorphic component
wasn't calling the finalization routine when I expected it to, so I wasn't
getting the deallocation that I was hoping for.

poly-leak-final.f90

But a variant of
that indicated to me that I was getting deallocation associated with
finalization that I wasn't hoping for!

poly-final-oddity.f90

What I'm not sure
about is whether allocatable components of finalizable type, that a members of
an entity that is not finalizable, are finalized when those components are
automatically deallocated when the containing entity goes out of scope. F2008 4.5.6.3 reads as if they should
("entities that are finalizable are finalized when they are
deallocated" - same text in F2003), but then that makes me wonder what the
significance of a non-finalizable entity is in the first place?? Some subtle change in ordering?? Does this also have implications for parent-extension type heirarchies??

Background: "A
derived type is finalizable if and only if it has a final subroutine or a
non-pointer, non-allocatable component of finalizable type."

For example, if:

TYPE :: a_finalizable_type
CONTAINS
  FINAL :: the_final_proc
END TYPE a_finalizable_type 

TYPE :: not_finalizable
  TYPE(a_finalizable_type), ALLOCATABLE :: alloc_comp
END TYPE not_finalizable

and a
local variable of type not_finalizable goes out of scope (or an allocatable variable of
type not_finalizable gets deallocated) with its alloc_comp component
allocated, will the_final_proc be called?

I hope that's what
supposed to happen with the language, as otherwise things are going to get
confusing (explicit deallocation of the component will invoke finalization,
automatic deallocation won't), but currently ifort thinks not.

Finally, in ifort
explicit deallocation of a component results in different behaviour whether the
component is polymorphic (with dynamic type different from the declared type)
or not.

poly-comp-final.f90

notpoly-comp-final.f90

Comments?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

With the release of 12.1 I was revising my 12.0 buglist and noticed that these might not have been picked up. For what it's worth I don't think there's any change here, including with the ICE.

Sorry - looks as if I dropped the ball on this. I will investigate and escalate as needed.

Retired 12/31/2016

I thought the update 6 compiler which became available today was still a 12.0, even though its installation conflicts with the 12.1 beta.
Oh, I see it is 12.1.6 and allows 12.0.5 to coexist.

Intel Visual Fortran Composer XE 2011 Update 6 includes Intel Visual Fortran Compiler 12.1.0. It also includes some other "interesting" features - read the release notes.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today