Language Reference

Definition Status of Variables

A variable is always defined or undefined, and its definition status can change during program execution. A named constant has a value and cannot be defined or redefined during program execution.

Arrays (including sections), structures, and variables of character or complex type are objects made up of zero or more subobjects. Associations can be established between variables and subobjects and between subobjects of different variables.

• An object is defined if all of its subobjects are defined. That is, each object or subobject has a value that does not change until it becomes undefined or until it is redefined with a different value.
• If an object is undefined, at least one of its subobjects is undefined. An undefined object or subobject cannot provide a predictable value.

Variables are initially defined if they are specified to have initial values by DATA statements, type declaration statements, or STATIC statements. In addition, default initialization may cause a variable to be initially defined. Zero-sized arrays and zero-length character objects are always defined.

All other variables are initially undefined.

Events Causing Definition

The following events will cause a variable to become defined:

1. Execution of an intrinsic assignment statement other than a masked array assignment statement or FORALL assignment statement causes the variable that precedes the equal sign to become defined.

   Execution of a defined assignment statement may cause all or part of the variable that precedes the equal sign to become defined.

2. Execution of a masked array assignment statement or FORALL assignment statement may cause some or all of the array elements in the assignment statement to become defined.
3. As execution of an input statement proceeds, each variable that is assigned a value from the input file becomes defined at the time that data are transferred to it. Execution of a WRITE statement whose unit specifier identifies an internal file causes each record that is written to become defined.

   As execution of an asynchronous input statement proceeds, the variable does not become defined until the matching WAIT statement is executed.

4. Execution of a DO statement causes the DO variable, if any, to become defined.

   +---------------------------------Fortran 95---------------------------------+

   
   
5. Default initialization may cause a variable to be initially defined.

   +-----------------------------End of Fortran 95------------------------------+

6. Beginning of execution of the action specified by an implied-DO list in an input/output statement causes the implied-DO variable to become defined.
7. Execution of an ASSIGN statement causes the variable in the statement to become defined with a statement label value.
8. A reference to a procedure causes the entire dummy argument data object to become defined if the dummy argument does not have INTENT(OUT), and the entire corresponding actual argument is defined with a value that is not a statement label.

   A reference to a procedure causes a subobject of a dummy argument that does not have INTENT(OUT) to become defined if the corresponding subobject of the corresponding actual argument is defined.

9. Execution of an input/output statement containing an IOSTAT= specifier causes the specified integer variable to become defined.
10. Execution of a READ statement containing a SIZE= specifier causes the specified integer variable to become defined.

    +-------------------------------IBM Extension--------------------------------+

    
    
11. Execution of a READ or WRITE statement in XL Fortran containing an ID= specifier causes the specified integer variable to become defined.
12. Execution of a WAIT statement in XL Fortran containing a DONE= specifier causes the specified logical variable to become defined.
13. Execution of a synchronous READ or WRITE statement in XL Fortran containing a NUM= specifier causes the specified integer variable to become defined.

    Execution of an asynchronous READ or WRITE statement containing a NUM= specifier does not cause the specified integer variable to become defined. The integer variable is defined upon execution of the matching WAIT statement.

    +----------------------------End of IBM Extension----------------------------+

14. Execution of an INQUIRE statement causes any variable that is assigned a value during the execution of the statement to become defined if no error condition exists.
15. When a character storage unit becomes defined, all associated character storage units become defined.

    When a numeric storage unit becomes defined, all associated numeric storage units of the same type become defined, except that variables associated with the variable in an ASSIGN statement become undefined when the ASSIGN statement is executed. When an entity of type DOUBLE PRECISION becomes defined, all totally associated entities of double precision real type become defined.

    A nonpointer scalar object of type nondefault integer, real other than default or double precision, nondefault logical, nondefault complex, nondefault character of any length, or nonsequence type occupies a single unspecified storage unit that is different for each case. A pointer that is distinct from other pointers in at least one of type, kind, and rank occupies a single unspecified storage unit. When an unspecified storage unit becomes defined, all associated unspecified storage units become defined.

16. When a default complex entity becomes defined, all partially associated default real entities become defined.
17. When both parts of a default complex entity become defined as a result of partially associated default real or default complex entities becoming defined, the default complex entity becomes defined.
18. When all components of a numeric sequence structure or character sequence structure become defined as a result of partially associated objects becoming defined, the structure becomes defined.
19. Execution of an ALLOCATE or DEALLOCATE statement with a STAT= specifier causes the variable specified by the STAT= specifier to become defined.
20. Allocation of a zero-sized array causes the array to become defined.
21. Invocation of a procedure causes any automatic object of zero size in that procedure to become defined.
22. Execution of a pointer assignment statement that associates a pointer with a target that is defined causes the pointer to become defined.
23. Invocation of a procedure that contains a nonpointer, nonallocatable, automatic object, causes all nonpointer default-initialized subcomponents of the object to become defined.
24. Invocation of a procedure that contains a nonpointer nonallocatable INTENT(OUT) dummy argument causes all nonpointer default-initialized subcomponents of the object to become defined.
25. Allocation of an object of a derived type where a nonpointer component is initialized by default initialization, causes the component and its subobjects to become defined.

    +---------------------------------Fortran 95---------------------------------+

    
    
26. In a FORALL statement or construct used in Fortran 95, the index-name becomes defined when the index-name value set is evaluated.

    +-----------------------------End of Fortran 95------------------------------+

    +-------------------------------IBM Extension--------------------------------+

    
    
27. If a THREADPRIVATE nonpointer nonallocatable variable that does not appear in a COPYIN clause is defined on entry into the first parallel region, each new thread's copy of the variable is defined.
28. If a THREADPRIVATE common block that does not appear in a COPYIN clause is defined on entry into the first parallel region, each new thread's copy of the variable is defined.
29. For THREADPRIVATE variables that are specified in a COPYIN clause, each new thread duplicates the master thread's definition, allocation and association status of these variables. Therefore, if the master thread's copy of a variable is defined on entry to a parallel region, each new thread's copy of the variable will also be defined.
30. For THREADPRIVATE common blocks that are in a COPYIN clause, each new thread duplicates the master thread's definition, allocation and association status of the variables in these common blocks. Therefore, if the master thread's copy of a common block variable is defined on entry to a parallel region, each new thread's copy of the common block variable will also be defined.
31. When a variable is specified in a FIRSTPRIVATE clause of a PARALLEL, PARALLEL DO, DO, PARALLEL SECTIONS, PARALLEL WORKSHARE, SECTIONS, or SINGLE directive, each new thread duplicates the master thread's definition and association status of the variable. Therefore, if the master thread's copy of a variable is defined on entry to a parallel region, each new thread's copy of the variable will also be defined.
32. For each variable, or variable inside a common block, specified in a COPYPRIVATE clause, then after the execution of the code enclosed in the SINGLE construct and before any threads in the team have left the construct, all copies of the variable become defined as follows:
    • If the variable has the POINTER attribute, then copies of the variable in other threads in the team have the same pointer association status as the copy of the variable belonging to the thread that executed the code enclosed in the SINGLE construct.
    • If the variable does not have the POINTER attribute, then copies of the variable in other threads in the team have the same definition as the copy of the variable belonging to the thread that executed the code enclosed in the SINGLE construct.

    +----------------------------End of IBM Extension----------------------------+

Events Causing Undefinition

The following events will cause a variable to become undefined:

1. When a variable of a given type becomes defined, all associated variables of different type become undefined. However, when a variable of type default real is partially associated with a variable of type default complex, the complex variable does not become undefined when the real variable becomes defined and the real variable does not become undefined when the complex variable becomes defined. When a variable of type default complex is partially associated with another variable of type default complex, definition of one does not cause the other to become undefined.
2. Execution of an ASSIGN statement causes the variable in the statement to become undefined as an integer. Variables that are associated with the variable also become undefined.
3. If the evaluation of a function may cause an argument of the function or a variable in a module or in a common block to become defined, and if a reference to the function appears in an expression in which the value of the function is not needed to determine the value of the expression, the argument or variable becomes undefined when the expression is evaluated.
4. The execution of a RETURN statement or END statement within a subprogram causes all variables that are local to its scoping unit, or that are local to the current instance of its scoping unit for a recursive invocation, to become undefined, except for the following:
   1. Variables with the SAVE or STATIC attribute.
   2. Variables in blank common.
   3. According to Fortran 90, variables in a named common block that appears in the subprogram and appears in at least one other scoping unit that is making either a direct or indirect reference to the subprogram. XL Fortran does not undefine these variables, unless they are part of a threadlocal common block.
   4. Variables accessed from the host scoping unit.
   5. According to Fortran 90, variables accessed from a module that also is referenced directly or indirectly by at least one other scoping unit that is making either a direct or indirect reference to the subprogram. XL Fortran does not undefine these variables.
   6. According to Fortran 90, variables in a named common block that are initially defined and that have not been subsequently defined or redefined. XL Fortran does not undefine these variables.
5. When an error condition or end-of-file condition occurs during execution of an input statement, all of the variables specified by the input list or namelist-group of the statement become undefined.
6. When an error condition, end-of-file condition, or end-of-record condition occurs during execution of an input/output statement and the statement contains any implied-DO lists, all of the implied-DO variables in the statement become undefined.
7. Execution of a defined assignment statement may leave all or part of the variable that precedes the equal sign undefined.
8. Execution of a direct access input statement that specifies a record that has not been written previously causes all of the variables specified by the input list of the statement to become undefined.
9. Execution of an INQUIRE statement may cause the NAME=, RECL=, and NEXTREC= variables to become undefined.
10. When a character storage unit becomes undefined, all associated character storage units become undefined.

    When a numeric storage unit becomes undefined, all associated numeric storage units become undefined unless the undefinition is a result of defining an associated numeric storage unit of different type (see (1) above).

    When an entity of double precision real type becomes undefined, all totally associated entities of double precision real type become undefined.

    When an unspecified storage unit becomes undefined, all associated unspecified storage units become undefined.

11. A reference to a procedure causes part of a dummy argument to become undefined if the corresponding part of the actual argument is defined with a value that is a statement label value.
12. When an allocatable entity is deallocated, it becomes undefined. Successful execution of an ALLOCATE statement for a nonzero-sized object for which default initialization has not been specified causes the object to become undefined.
13. Execution of an INQUIRE statement causes all inquiry specifier variables to become undefined if an error condition exists, except for the variable in the IOSTAT= specifier, if any.
14. When a procedure is invoked:
    1. An optional dummy argument that is not associated with an actual argument is undefined.
    2. A nonpointer dummy argument with INTENT(OUT) and its associated actual argument are undefined.
    3. A pointer dummy argument with INTENT(OUT) and its associated actual argument have an association status of undefined.
    4. A subobject of a dummy argument is undefined if the corresponding subobject of the actual argument is undefined.
    5. The function result variable is undefined, unless it was declared with the STATIC attribute and was defined in a previous invocation.
15. When the association status of a pointer becomes undefined or disassociated, the pointer becomes undefined.

    +---------------------------------Fortran 95---------------------------------+

    
    
16. When the execution of a FORALL statement or construct in Fortran 95 has completed, the index-name becomes undefined.

    +-----------------------------End of Fortran 95------------------------------+

    +-------------------------------IBM Extension--------------------------------+

    
    
17. When a variable is specified in either the PRIVATE or LASTPRIVATE clause of a PARALLEL, PARALLEL DO, DO, PARALLEL SECTIONS, PARALLEL WORKSHARE, SECTIONS or SINGLE directive, each new thread's copy of the variable is undefined when the thread is first created.
18. When a variable is specified in a FIRSTPRIVATE clause of a PARALLEL, PARALLEL DO, DO, PARALLEL SECTIONS, PARALLEL WORKSHARE, SECTIONS or SINGLE directive, each new thread duplicates the master thread's definition and association status of the variable. Therefore, if the master thread's copy of a variable is undefined on entry to a parallel region, each new thread's copy of the variable will also be undefined.
19. When a variable is specified in the NEW clause of an INDEPENDENT directive, the variable is undefined at the beginning of every iteration of the following DO loop.
20. When a variable appears in asynchronous input, that variable becomes undefined, and remains undefined, until the matching WAIT statement is reached.
21. If a THREADPRIVATE common block or a THREADPRIVATE variable is specified in a COPYIN clause, each new thread duplicates the master thread's definition, allocation and association status of the variables. Therefore, if the master thread's copy of a variable is undefined on entry to a parallel region, each new thread's copy of the variable will also be undefined.
22. If a THREADPRIVATE common block or a THREADPRIVATE variable has the ALLOCATABLE attribute, the allocation status of each copy created will be, not currently allocated.
23. If a THREADPRIVATE common block or a THREADPRIVATE variable has the POINTER attribute with an initial association status of disassociated through either default or explicit initialization, each copy will have an association status of disassociated. Otherwise the association status of each copy is undefined.
24. If the THREADPRIVATE common block or a THREADPRIVATE variable has neither the ALLOCATABLE or the POINTER attribute and is initially defined through default or explicit initialization, each copy has the same definition. Otherwise, each copy is undefined.

    +----------------------------End of IBM Extension----------------------------+