This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/46321] [OOP] Polymorphic deallocation
- From: "janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 08 Aug 2013 14:36:31 +0000
- Subject: [Bug fortran/46321] [OOP] Polymorphic deallocation
- Auto-submitted: auto-generated
- References: <bug-46321-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from janus at gcc dot gnu.org ---
Indeed all the items from comment 1 to 3 seems to be handled. Below is a test
case, whose dump shows a _final call being created for all of them.
The only exception is realloc-on-assignment, which is not implemented yet for
CLASS variables, but there is PR 43366 to track that.
Therefore this PR can be closed, I think.
program p
type t
end type t
type u
class(t), allocatable :: c
end type
class(t), allocatable :: a,b
type(u), allocatable :: uu
integer :: i
character(len=100) :: str
allocate(a,b,uu)
! (1) explicit deallocation
deallocate(a)
! (4) STAT and ERRMSG
deallocate(a,stat=i,errmsg=str)
if (i/=0) print *,i,str
! (5) dealloc of comp.
deallocate(uu)
! (6) move_alloc
call move_alloc(b,a)
contains
subroutine out (x)
! (2) intent(out)
class(t), intent(out) :: x
end subroutine
subroutine sub ()
! (3) out of scope
class(t), allocatable :: local
allocate(local)
end subroutine
end