DO CONCURRENT (Fortran 2008)

Purpose

The DO CONCURRENT statement is the first statement in the DO CONCURRENT construct, which allows you to specify that individual loop iterations have no interdependencies.

Syntax

where concurrent_header is:

where concurrent_control is:

DO_construct_name: is a name that identifies the DO CONCURRENT construct.
stmt_label: is the statement label of an executable statement that appears after the DO CONCURRENT statement in the same scoping unit. It denotes the end of the DO CONCURRENT construct.
scalar_mask_expr: is a scalar logical expression. It is evaluated for each combination of index-name values the same way as if it were used in the FORALL construct.
index_name: is a named variable that is a scalar integer. It has a scope of the DO CONCURRENT construct.
concurrent_limit, concurrent_step: are both scalar integer expressions. They can be evaluated in any order that is valid in the FORALL construct.

Constraints

concurrent_limit or concurrent_step in a concurrent_control must not contain a reference to any index_name in the concurrent_control_list in which the concurrent_limit or concurrent_step parameter appears.
A CYCLE statement must not appear within a DO CONCURRENT construct if it belongs to an outer construct.
A RETURN statement must not appear within a DO CONCURRENT construct.
A branch within a DO CONCURRENT construct must not have a branch target that is outside the construct.
A reference to a nonpure procedure must not appear within a DO CONCURRENT construct.
A reference to the procedure IEEE_GET_FLAG, IEEE_SET_HALTING_MODE, or IEEE_GET_HALTING_MODE from the intrinsic module IEEE_EXCEPTIONS must not appear within a DO CONCURRENT construct.
An EXIT statement must not appear within a CRITICAL or DO CONCURRENT construct if it belongs to that construct or an outer construct.

Rules

If the DO statement of a DO construct specifies a DO_construct_name, the corresponding END_DO_statement must specify the same DO_construct_name; otherwise, the corresponding END_DO_statement must not specify a DO_construct_name.

Execution of a CYCLE statement that belongs to a DO CONCURRENT construct completes execution of that iteration of the construct.

If integer_type_spec appears in concurrent_header, it has the specified type and type parameters; otherwise, the following rules apply:

Its type and type parameters are the same as the type and type parameters it would have if it were the name of a variable in the innermost executable construct or scoping unit. In addition, this type must be integer.
An index_name must not be the same as an accessible global identifier, local identifier, or identifier of an outer construct entity, except for a common block name or a scalar variable name.

The set of combinations of index_name values is the Cartesian product of the sets that is defined by each control specification. The set of combinations of index_name values is active when scalar_mask_expr has the value .TRUE.. An index_name becomes defined when this set is evaluated. The range of a DO CONCURRENT construct is executed for every active combination of the index_name values. Each execution of the range is an iteration. The executions might occur in any order.

An index_name of a contained DO CONCURRENT construct must not be the same as an index_name of any of its containing DO CONCURRENT constructs.

For a DO CONCURRENT construct, the loop terminates and the DO construct becomes inactive when execution of all the iterations is completed.

When a DO CONCURRENT construct terminates, the following rules apply:

The association status of a pointer is processor dependent if the pointer’s association status was changed in more than one iteration of the construct.
A variable that is defined or becomes undefined during more than one iteration of the construct becomes undefined.

The ordering among records that are written by different iterations of a DO CONCURRENT construct is processor dependent if the records are written to a file that is connected for sequential access by more than one iteration.

The following rules are related to execution of a DO CONCURRENT construct:

A variable that is referenced in an iteration must either be previously defined during that iteration, or must not be defined or become undefined during any other iteration. A variable that is defined or becomes undefined by more than one iteration becomes undefined when the loop terminates. This rule applies to any procedure that is invoked within the loop.
If a pointer is used in an iteration other than in the case of pointer assignment, allocation, or nullification, it must either be previously pointer associated during that iteration or must not have its pointer association changed during any other iteration. A pointer that has its pointer association changed in more than one iteration has an undefined association status when the construct terminates.
If an allocatable object is referenced, defined, deallocated, or has its allocation status, dynamic type, or a deferred type parameter value inquired about in an iteration, it must either be previously allocated in that iteration or must not be allocated or deallocated in any other iteration. If an allocatable object is allocated in more than one iteration, it must have an allocation status of unallocated at the end of every iteration.
If data are written to a file record or position in one iteration, that record or position in that file must not be read from or written to in a different iteration.