Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

deallocate in Select Type

StevenGamm
Beginner
222 Views

Hello, I'm trying to use deallocate in the Select Type structure, but this is not true:

error #6724: An allocate/deallocate object must have the ALLOCATABLE or POINTER attribute.

 

I have to use the code in comment lines, but that makes the code redundant

Gfortran compiles and runs the same code.

 

Thank you!

Module typedef
implicit none
type :: T_Main
end type T_Main

type , extends(T_Main) :: T_Sub
contains
Final :: fn
end type T_Sub

contains

Subroutine fn(this)
type(T_Sub) , target :: this
write(*,*) "Final it!"
End Subroutine fn

End Module typedef

program main
use typedef
implicit none
class(T_Main) , pointer :: pMain
type(T_Sub) ,target, allocatable :: pSub
!type(T_Sub) , pointer :: pSub2
allocate(pSub)
pMain => pSub

Select Type( pv => pMain )
Class Is( T_Sub )
!pSub2 => pSub
!deallocate(pSub2)
deallocate(pv)
End Select
end program main

0 Kudos
2 Replies
FortranFan
Honored Contributor II
184 Views

@StevenGamm ,

 

As shown in the original post, the code does not conform to the Fortran standard.  Intel Fortran conforms to the standard by issuing a diagnostic.

Given the Fortran standard and the tremendous benefit it provides with the ALLOCATABLE attribute on objects, one does not need explicit finalization, explicit "garbage collection" in the form of DEALLOCATE, etc.  If you post your use case here (or at Fortran Discourse https://fortran-lang.discourse.group/ on all matters pertaining to Fortran generally), readers may be able to guide you to other, possibly simpler solutions that position you better than the one above where another Fortran compiler disagrees with the standard and causes you doubt.

 

Steve_Lionel
Black Belt Retired Employee
184 Views

That is the correct behavior. Quoting the standard (emphasis mine):

Within an ASSOCIATE, CHANGE TEAM, or SELECT TYPE construct, each associating entity has the same rank as its associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND (16.9.109) applied to the corresponding dimension of selector. The upper bound of each dimension is one less than the sum of the lower bound and the extent. The associating entity does not have the ALLOCATABLE or POINTER attributes; it has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute

Reply