(j3.2006) automatically deallocating unallocated allocatable variables

Bill Long longb
Sun Jan 9 23:51:29 EST 2011

On 1/8/11 1:48 AM, Robert Corbett wrote:
> The citations given here are for 10-007r1.
> Paragraphs 2 and 3 of Clause [130:24-27] state
>        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 thereof;
>        otherwise, it is deallocated.
>        When a BLOCK construct terminates, an unsaved allocatable local
>        variable of the construct is deallocated.

In both cases, I think the intent is "clearly"  that the variable is 
deallocated only if it was allocated at the indicated point.  Some 
wording improvement might be in order. I don't know of any 
implementation that gets this wrong.


> Paragraph 10 of Clause [131:10] states
>        The effect of automatic deallocation is the same as that of a
>        DEALLOCATE statement without a /dealloc-opt-list/.
> Paragraph 1 of Clause 6,7,3,2 [130:21] states
>        Deallocating an unallocated allocatable variable causes an
>        error condition in the DEALLOCATE statement.
> Paragraph 3 of Clause [130:15-17] states
>        If an error condition occurs during execution of a DEALLOCATE
>        statement that does not contain the STAT= specifier, error
>        termination is initiated.
> Taken together, these statements say that if an unsaved allocatable
> local variable (with the exception of a function result variable in
> the case of a procedure) is unallocated at the end of execution of
> a procedure or a BLOCK construct, error termination is initiated.
> Is this intended?
> If a DEALLOCATE statement contains an ERRMSG= specifier but not a
> STAT= specifier, error termination is initiated whenever the processor
> would assign a value to the /errmsg-variable/.  I suppose the effect
> of the assignment might be detected if the /errmsg-variable/ has the
> VOLATILE sttribute.
> Robert Corbett
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the J3 mailing list