To: J3 Members J3/16-199 From: Van Snyder Subject: Problems with locality specs in DO CONCURRENT References: 16-007r1 Date: 2016 May 23 4.5.6.3p4 says that a nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it would become undefined due to termination of the BLOCK construct. There is no parallel description for variables that have LOCAL or LOCAL_INIT locality in a DO CONCURRENT construct. 16.6.4 says variables that are not initially defined are undefined. Variables of a DO CONCURRENT construct that have LOCAL locality become undefined when execution of each iteration of the construct begins. This cannot be covered by 16.6.4 because local variables of a subprogram that have the SAVE attribute but not initialization are initially undefined (i.e., when the program begins execution), but if execution of the subprogram defines them, they are still defined upon subsequent invocation of the subprogram. So "initially" in 16.6.4 can only mean "when the program commences execution." The attributes of variables with LOCAL or LOCAL_INIT locality are incompletely specified, or are inconsistent with the attributes a variable could have if it were declared within a BLOCK construct within the DO CONCURRENT construct. There is no specification whether a variable eoyj LOCAL or LOCAL_INIT locality is or is not polymorphic. It is prohibited to be allocatable, which means that if it is polymorphic a value cannot be assigned to it by intrinsic assignment. It cannot be of a type with the BIND attribute, or be the name of a variable that has the BIND attribute. It cannot be a coarray. It cannot be finalizable. These prohibitions do not exist for variables declared within a BLOCK construct within the DO CONCURRENT construct. I am not convinced that the above is an exhaustive list of what would have been interp bait concerning locality specs for DO CONCURRENT constructs. We have stiven to eliminate implicit properties. IMPLICIT NONE was introduced in Fortran 90. Most textbooks recommend its use. Most developers' style guides of which I am aware require its use. It was the default in some alternatives to Fortran, for example F and ELF. There have been requests that it ought to be the default in Fortran. IMPLICIT NONE (EXTERNAL) has been requested repeatedly, and we have finally provided it. One of the objections to statement functions is that their arguments are implicitly typed. Introducing more implicit properties is a bad idea. In the current revision, locality specs ought to be deleted. The excuse that we have to provide them because OpenMP did is nonsense. OpenMP did it wrongly, or at least incompletely. Simply copying a few of OpenMP's half-baked ideas, like undefined allocation status, without considering that there might be (or definitely are) better ways of accomplishing the same ends using concepts that fit the Fortran gestalt, perpetuates the "beloved Fortran tacked-on look" about which university computer science professors snicker, and from which they believe they have good reason to refuse to teach Fortran. The excuse that we don't have sufficient syntactic sugar for LOCAL_INIT rings a bit hollow as well, since syntax for local automatic reinitialization without acquiring the SAVE attribute has been requested for decades. In the next revision after Fortran 2015, the DO CONCURRENT construct ought to have a specification part. Indeed, the of every construct ought to have a specification part. This is not exactly a new concept. It existed in Algol in 1960. Algol 60 did not spring fully-formed from the forehead of Zeus, so somebody was clearly contemplating this concept nearly sixty years ago. It has been requested for Fortran repeatedly. I requested it in 97-114, nearly twenty years ago. I do not have my paper correspondence with X3J3 from during the time of development of Fortran 90, and e-mail correspondence was not archived before about 1997. Having studied and used Pascal, Modula 2, and Ada, I might have requested it before 1997, but I have no firm recollection of whether that is true. Until the of the DO CONCURRENT construct, or better the of every construct, has a specification part, textbooks can recommend using a BLOCK construct within a DO CONCURRENT construct. The alternative for them (and us) is the weird irregular complication of the DO CONCURRENT locality specs. 2. Edits ======== [xviii intro under "Data usage and computation"] Delete "The locality ... explicitly specified." [181:13 R823] Delete "" [181:20-24 R829-R830] Delete syntax rules R829 and R830. [181:30-39 C825-C828] Delete constraints C825, C826, C827 and C828. [182:1-6 C829-C830] Delete constraints C829 and C830. [185:1-24 8.1.7.5p1-3] Delete 8.1.7.5p1-3 [185:25 8.1.7.5p4] Replace the introduction to the list with "If a variable appears within a DO CONCURRENT construct and" [185:26,29,32,34,36 8.1.7.5p4] Replace "if it" with "it" five times. [185:38+ 8.1.7.5p4+] Insert NOTE 8.9a: "NOTE 8.9a If it is necessary or desirable to specify explicitly that a variable is not to be shared between iterations, it should be declared within a BLOCK construct within the DO CONCURRENT construct." [506:11-12 16.4p1] Delete "A variable that has LOCAL or LOCAL_INIT locality in a DO CONCURRENT construct is a construct entity." [506:36-37 16.4p6] Delete 16.4p6, viz. "A variable that has LOCAL or LOCAL_INIT locality in a DO CONCURRENT construct has the scope of that construct. Its attributes are specified in 8.1.7.5." [513:24-25 16.5.2.5p1(13)] Delete list item (13), viz. "An iteration of a DO CONCURRENT construct completes and the pointer is associated with a variable of that construct that has LOCAL or LOCAL_INIT locality." [519:35-36 16.6.5p1(26)] Delete list item (26), viz. "In a DO CONCURRENT construct, a variable with LOCAL_INIT locality becomes defined at the beginning of each iteration." [521:30-31 16.6.6p1(18)] Delete list item (18), viz. "When execution of an iteration of a DO CONCURRENT construct completes, a construct entity of that construct which has LOCAL or LOCAL_INIT locality becomes undefined."