To: J3 J3/17-242r1 From: Dan Nagle & Malcolm Cohen Subject: scope of prohibition of DO CONCURRENT Date: 2017 October 17 Introduction Paper 183 discusses whether variable declarations in scopes nested within the block of a DO CONCURRENT are allowed when DEFAULT ( NONE ) is present. Subgroup finds the standard is unclear; while it is likely allowed, it is not clear that "appears", in C1129, applies to the scope rather than the inclusive scope of the DO CONCURRENT block. An edit is supplied to clarify the point. Also, SAVEd variables in nested constructs need to have SHARED locality, to get the restrictions on use that allow parallelization. Edits {against 17-007r2} {11.1.7.2 Form of the DO construct} The present C1129: [191:26-28] "C1129 If the locality-spec DEFAULT ( NONE ) appears in a DO CONCURRENT statement, a variable that appears in the block of the construct and is not an index-name of that construct shall have its locality explicitly specified." Change "appears in the block of the construct and is not an index-name of that construct" to "is a local or construct entity of a scope containing the DO CONCURRENT construct, and that appears in the block of the construct,", So the resulting constraint will read "C1129 If the locality-spec DEFAULT ( NONE ) appears in a DO CONCURRENT statement, a variable that is a local or construct entity of a scope containing the DO CONCURRENT construct, and that appears in the block of the construct, shall have its locality explicitly specified. [194:24] 11.1.7.5 Additional semantics for DO CONCURRENT constructs, p1, Append "A construct or statement entity of a construct or statement within the DO CONCURRENT construct has SHARED locality if it has the SAVE attribute. If it does not have the SAVE attribute, it is a different entity in each iteration, similar to LOCAL locality." {Clarify what happens with contained entities: it is important that SAVEd entities suffer the restrictions of SHARED locality to avoid communication between iterations.}