Intel® Fortran Compiler Classic and Intel® Fortran Compiler Developer Guide and Reference

ID 767251
Date 6/24/2024
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

Deallocation of Allocatable Variables

Deallocating an unallocated allocatable variable causes an error condition in the DEALLOCATE statement.

Deallocating an allocatable variable results in undefined behavior if either or both of the following is true:

  • The variable, or any subobject of the variable, is construct associated with an associating entity.

  • The variable, or any subobject of the variable, is argument associated with a dummy argument.

Deallocating an allocatable variable with the TARGET attribute causes the pointer association status of any pointer associated with it to become undefined.

When the execution of a procedure is terminated by execution of a RETURN or END statement, an unsaved allocatable local variable of the procedure retains its allocation and definition status if it is a function result variable or a subobject of one; otherwise, it is deallocated.

When the execution of a BLOCK construct terminates at the END BLOCK statement, an unsaved allocatable variable declared in the block and whose allocation status is allocated is deallocated.

If an executable construct references a function whose result is either allocatable or a structure with a subobject that is allocatable, and the function reference is executed, an allocatable result and any subobject that is an allocated allocatable entity in the result returned by the function is deallocated after execution of the innermost executable construct containing the reference.

If a function whose result is either allocatable or a structure with an allocatable subobject is referenced in the specification part of a scoping unit, and the function reference is executed, an allocatable result and any subobject that is an allocated allocatable entity in the result returned by the function is deallocated before execution of the executable constructs of the scoping unit.

When a procedure is invoked, any allocated allocatable object that is an actual argument corresponding to an INTENT (OUT) allocatable dummy argument is deallocated. Any allocated allocatable object that is a subobject of an actual argument corresponding to an INTENT (OUT) dummy argument is deallocated.

When an intrinsic assignment statement is executed, any noncoarray allocated allocatable subobject of the variable is deallocated before the assignment takes place.

When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated.

If an allocatable component is a subobject of a finalizable object, that object is finalized before the component is automatically deallocated.

The effect of automatic deallocation is the same as that of a DEALLOCATE statement without a dealloc-opt argument.

When a DEALLOCATE statement is executed for which an object is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment following the statement is delayed until all other images have executed the same statement the same number of times. If the coarray is a dummy argument, its ultimate argument must be the same coarray on every image.

There is also an implicit synchronization of all images in association with the deallocation of a coarray or coarray subcomponent caused by the execution of a RETURN or END statement.

The intrinsic function ALLOCATED can be used to determine whether a variable is allocated or unallocated.

Consider the following example:

SUBROUTINE PROCESS
   REAL, ALLOCATABLE :: TEMP(:)
   REAL, ALLOCATABLE, SAVE :: X(:)
   ...
END SUBROUTINE PROCESS

Upon return from subroutine PROCESS, the allocation status of X is preserved because X has the SAVE attribute. TEMP does not have the SAVE attribute, so it will be deallocated if it was allocated. On the next invocation of PROCESS, TEMP will have an allocation status of unallocated.