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, Fortran 2008 beginsin a submoduleFortran 2008 ends, 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=, NEXTREC=, and POS= 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= or IOMSG= 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, except for nonpointer direct components that have default initialization.
    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.
  16. When the execution of a FORALL statement or construct in Fortran 95 has completed, the index-name becomes undefined.
  17. Fortran 2003 begins When execution of a RETURN or END statement causes a variable to become undefined, any variable of type C_PTR becomes undefined if its value is the C address of any part of the variable that becomes undefined.
  18. When a variable with the TARGET attribute is deallocated, any variable of type C_PTR becomes undefined if its value is the C address of any part of the variable that is deallocated. Fortran 2003 ends
  19. IBM extension begins 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.
  20. When a variable is specified in the PRIVATE clause of a TASK directive, each private copy of the variable is undefined when the task is first generated.
  21. When a variable is specified in a FIRSTPRIVATE clause of a PARALLEL, PARALLEL DO, DO, PARALLEL SECTIONS, PARALLEL WORKSHARE, SECTIONS, SINGLE or TASK 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.
  22. 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.
  23. When a variable appears in asynchronous input, that variable becomes undefined, and remains undefined, until the matching WAIT statement is reached.
  24. 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.
  25. If a THREADPRIVATE common block variable or a THREADPRIVATE variable has the ALLOCATABLE attribute, the allocation status of each copy created will be not allocated.
  26. If a THREADPRIVATE common block variable 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.
  27. If a THREADPRIVATE common block variable or a THREADPRIVATE variable has neither the ALLOCATABLE nor the POINTER attribute and is initially defined through default or explicit initialization, each copy has the same definition. Otherwise, each copy is undefined. IBM extension ends
  28. Fortran 2008 begins When execution of a BLOCK construct is complete:
    1. An unsaved, local variable of the BLOCK construct becomes undefined.
    2. A variable of type C_PTR becomes undefined if its value is the C address of an unsaved, local variable of the BLOCK construct.
    Fortran 2008 ends
  29. An object with the VOLATILE attribute might become undefined when the undefinition is not specified in the program.
Parent topic: Definition status of variables


Voice your opinion on getting help information Ask IBM compiler experts a technical question in the IBM XL compilers forum Reach out to us