To: J3 J3/13-359 From: Bill Long Subject: Editor notes on creating 13-358 Date: 2013 November 07 References: N1983, N1989, J3/13-358 Discussion ---------- This paper contains notes related to the incorporation of edits into N1983.pdf to create 13-358.pdf. There are three sections. The first contains comments corresponding to the incorporation of passed papers from meeting 202 that had edits affecting N1983. The second part contains additional edits made to fix integration problems and oversights found after proofreading the result of incorporating the papers. The third part documents remaining issues with the TS. I. Notes on edits from papers incorporated ------------------------------------------ Paper 13-333r2: [21:33] Reverse the order of 7.4.13 SUBTEAM_ID and 7.4.14 TEAM_DEPTH to retain alphabetical order after the change SUBTEAM_ID -> TEAM_ID. [30:12-13] Reverse the order of (now) TEAM_ID and TEAM_DEPTH to retain alphabetical order after the change SUBTEAM_ID -> TEAM_ID. [10:13] Changed "a call to GET_TEAM()" to "a reference to the intrinsic subroutine GET_TEAM (7.4.13)". [22:40] Change "Populate" to "Define" in description of GET_TEAM. Corresponding edits in Clause 8. [22:40] In the first example, change the comment to "! Define a team variable representing the initial team". The statement does not "declare" a variable. Paper 13-334r3: [29:41+] This edit is clearly at the wrong place, and has several problems as follows: 1) The text describing STAT_ALREADY_POSTED needs to be subclause 6.5 of the main TS and include a sentence saying it is defined in ISO_FORTRAN_ENV, with that sentence deleted as part of the Clause 8 edits moving the section to the base standard. 2) The edit at [13:29] should end with "(6.5)" instead of "from the intrinsic module ISO_FORTRAN_ENV". 3) In the edit for [13:29] first sentence change "causes an error condition" to "an error condition occurs". {Original sentence lacked a subject.} 4) The paragraph describing STAT_ALREADY_POSTED needs to have "greater than" changed to "greater than or equal to" to be consistent with the description at added to the end of 6.3. 5) The edit to insert this into Clause 13 of the main standard belongs at [31:14+] and the insert subclause number is 13.8.2.21a. {The 13.8.2.1a number was for ALREADY_POSTED which is in a different location alphabetically.} The text of the edit is just to move the text of 6.5 to the corresponding section of 13.8.2. 6) In the edit that moves EVENT POST to Clause 8 of the main standard [28:2-3] change "modified." to "modified, and the "(6.5)" at the end of the paragraph of text to "from the intrinsic module ISO_FORTRAN_ENV" ". Paper 13-335r3: [9:28] An edit to C501 allows a team variable to appear in DEALLOCATE. That should also be added to C502. [29:3+] Add a missing comma to the edit and change ending punctuation to a comma. Paper 13-336r2: [9:37] The edit to append [, is awkward and inconsistent with the syntax of CHANGE TEAM. Instead, have the optional be in parens and before the . [10:13-14] Change to "CHANGE TEAM statement". Statements get executed, not syntax terms. [10:15] Change "change-team block" to "CHANGE TEAM ". [10:25] Appear to have missed on "nonfailed"; added. [11:17] Edit also has the effect of deleting the effect of deleting the replacement of this paragraph in 13-335r3. Paper 13-337r1: [10:34] Changed "" to "". [26:30] Added "(8.5.2c)" after "FORM TEAM statement". [33:13, 26, 28] Changed "SUBTEAM_SURFACE_TYPE" to "TEAM_SURFACE_TYPE" instead of "SURFACE_TYPE" because the example code already had a different variable named SURFACE_TYPE. Paper 13-340r2: [12:4] At the end of the paragraph describing STAT_FAILED_IMAGE a sentence is needed saying it is defined in ISO_FORTRAN_ENV, with that sentence deleted as part of the Clause 8 edits moving the section to the base standard. Paper 13-342r1: [13:9-10] Make the EVENT_QUERY change of "difference between..for the event variable" to "number of successful posts minus the number of successful waits" here as well. [31:29] In the edit change "posts" to "event posts" to give better context. Paper 13-343r2: [21:10-11] In the replacement edit change "If" to It". {fix typo} [21:11] Delete "with" before "a processor-dependent" to adjust for the change from "becomes defined with" to "is assigned". Paper 13-344r2: [17:7] says that OLD is type integer - should be the same type as ATOM (which is allowed to be LOGICAL) [16:25] (and similar) the change "is a named constant in the intrinsic module" to "is the named constant in the intrinsic module" seems to suggest there is only one constant in the module. Change all to "a". Paper 13-345r2: [15:39+] Note moved a few lines down to the end of the subclause. [19:33] Change "value" to "result" to be parallel to the edit at [19:30]. Paper 13-346r2: [30:4] Also change "variable" to "value" to limit line length. Same change in Clause 7. [31:29+] Add "from this Technical Specification" to correctly identify the source text. Merge the edits for C.10.2 and C.10.3, and convert to pure editorial directions. [34:40+] Add a similar heading for the new example in this section. Paper 13-347r2: (no comments) Paper 13-350r1: Change the beginning of the existing example in A.1 to "Example 1" and add "Example 2: " at the beginning of the new example. Paper 13-354r2: [28:25-27] The paragraph before the edit in this paper contains the old style phrase "become defined with the value zero", inconsistent with the text in the new paragraph that follows. Updated the previous paragraph wording. Paper 13-355r2: [29:13] - This edit appears to be intended for [29:12]. In the text "sequence or atomic memory operations" changed "or" to "of". [31:30+] Added "from this Technical Specification" after "A.3.2". The base standard style is to uppercase the names of language intrinsics. For consistency those changes were made in the example codes. Added the ",INTRINSIC" to the USE for ISO_FORTRAN_ENV. II. Additional editorial repairs --------------------------------- After entering the paper edits into the LaTeX sources, the resulting PDF file exposed several problems, including wording inconsistencies, typos, missing edits needed for proper integration, and conflicting text. Many of those were repaired as indicated in this section. Remaining problems are noted in the "Issues" section at the end of this paper. All clauses: The phrase "in the intrinsic module ISO_FORTRAN_ENV" is used in F2008 and some places in the TS. Variations in the TS that begin with "from" or put the "intrinsic module" at the end are changed to match the F2008 form. Clause 3: 3a) Fixed references at the end of term definitions. 7.2 is now 7.3, and the term "parent team" is introduced in 5.1, not 5.4. 3b) The definition for "team" does not account for the new capability to access data outside the team. Instead, change the definition to use the words at the beginning of 5.1. Clause 5: 5a) Edits in Clause 8 introduce the requirement that an explicit interface is required if the called procedure has an argument of type TEAM_TYPE. This needs to be stated in 5.2. Text added after 5.2 para 2. 5b) In C502, change "to a GET_TEAM call" to "in a reference to the intrinsic subroutine GET_TEAM". {Corrected style.} 5c) In C502 and C503 the phrases "with an explicit interface" is redundant now that explicit interfaces are already required for in those cases. Remove "with an explicit interface" twice. 5d) In the final sentence of 5.2 insert "of the current" after "ancestor. {Wording consistency}. 5e) In the first para following the constraints in 5.3, the first and last sentences ended up contradicting each other. The last sentence was replaced with "The current team for the statements of the CHANGE TEAM is the team specified by ." This replaces the wrong text and also needs to be included in normative text. 5f) In 5.3, para beginning "An allocatable coarray" replace "" with "CHANGE TEAM" twice. {The syntax term is not a construct.} 5g) In the last para of 5.4 before Note 5.2, change "a call to GET_TEAM" to "a reference to the intrinsic subroutine GET_TEAM". {Corrected style.} 5h) Both IF statements in the new Note 5.2 in subclause 5.4 have defective syntax. Changed "=" to "==". 5i) In 5.5, last sentence before notes, added missing comma after "occurs". 5j) In 5.6, second sentence fails to account for the new possibility that the team variable could have been defined by GET_TEAM. Added wording similar to the corresponding sentence in 5.3. {Integration oversight.} 5k) In 5.6, sentence 3, insert "executing" after "synchronization of the" {clearer wording}. Clause 6: 6a) 6.1 contains a mix of statement and action references. Changed "use an EVENT POST statement" to "post an event". {Make sentence uniformly about actions.} 6b) In C602 and C603, add exclusion for an EVENT_TYPE variable to appear in a DEALLOCATE statement, parallel to the TEAM_TYPE constraints. {Assume the argument about memory leaks that motivated the TEAM_TYPE change applies here as well. Integration oversight.} 6c) Change the end of C604 to just a reference to (6.2) to match the style of F2008. 6d) In 6.5 STAT_ALREADY_POSTED, need to say that the value is different from STAT_FAILED_IMAGE or STAT_STOPPED_IMAGE, similar to the first sentence of 5.7 STAT_FAILED_IMAGE. {Integration oversight.} Clause 7: 7a) The new second paragraph in 7.2, about the lack of a formal data consistency model, is has multiple defects. The statement "An inconsistent module would be worse...processor-dependent" reads like a personal opinion and is not appropriate for normative text in a TS. Additionally, the TS always refers to the base standard by its ISO identifier. Finally, I don't think we want to wait until after integration to consider this issue. Replace the whole second sentence with "Developing a formal data consistency model is left until the integration of these facilities into ISO/IEC 1539-1." 7b) In 7.3 Collectives, insert two missing "nonfailed" qualifiers for images. You cannot require a failed image to call a subroutine. {Integration oversight} 7c) In 7.3 para 3, delete the initial "All the". {Wording improvement} 7d) In 7,3 para 4, reword sentence to convert from "becomes defined with" form to "is assigned". {Wording regularization.} 7e) In 7.3 para 5, after "is assigned a nonzero value, " insert "and". {Missing word.} 7f) New Notes 7.2 and 7.3 appear contradictory (7.2 starts "Each collective involves partial synchronization", where as 7.3 starts "There is no synchronization..."). Also Note 7.3 starts a sentence "Note that" which seems out of place. Combined the notes into one new Note 7.2 that avoids the conflict. 7g) In 7.4 CO_REDUCE, the OPERATOR description says that the function has to be the same twice. Delete the first one (second sentence of the description). 7h) In the example code for GET_TEAM, inserted "current" in the comment that now reads "Reference image 1 in my current team" to better compare with the previous comment. {Wording improvement} 7i) The revised description of NUM_IMAGES fails to specify the result in the case that DISTANCE is present but FAILED is not. Reword to link DISTANCE to the "team specified". 7j) The STAT argument for all of the collective intrinsics is a "scalar integer". This effectively limits the size of the values to the smallest KIND of integer available in the implementation, which could be unreasonable. In the F2008 intrinsic subroutines with INTENT(OUT) status arguments, the requirement is default integer. That is also the case for EVENT_QUERY in the TS. Made that change for the collectives. Clause 8: In 8.2, the first bullet (teams) is now too restrictive in that teams do not necessarily restrict remote memory references to the current team, and also synchronizations are not restricted to the current team. Reworded to say this is a capability rather than a restriction. In 8.2 the second bullet added "of the current team" following "all the images". {Integration oversight} In 8.2, the third bullet (atomic memory operations) overlooks the capability of global accumulations, independent of synchronization. Added extra text at the end to include this. In 8.3, correct reference for "parent team" to be 2.3.4. In 8.3, remove the periods at the end of the term definitions, to match the form in f2008. In 8.4, delete the replacement text, and instead expand the edit instruction to copy the paragraphs from 5.1 with noted changes. {The texts are now out of sync and this seems like a better solution.} In 8.6, the text for the second edit (for 6.6 Image selectors) is out of date because it lacks the GET_TEAM text. Copy correct text from 5.4 of the TS, adding references. {Integration oversight} In 8.7, edit beginning "Following 8.5.2 Segments insert 6.3 EVENT POST.." correct the reference changes to match the new text. In 8.7, penultimate edit final paragraph concerns which statements have the effect of a SYNC MEMORY statement if the STAT= value is not zero. The list contradicts the statement in the edit for 8.5.1 Image control statements, para 3, and also the text in F2008. Delete FORM TEAM, LOCK, and UNLOCK from this list. {Fix wrong text}. In 8.9, edits for NUM_IMAGES, make changes corresponding to 7i above. III. Remaining Issues: ---------------------- Clause 5: I-5) Note 5.1 explains that an implementation is responsible for deallocating coarrays at the end of an CHANGE TEAM construct. This is not trivial, since a coarray with the SAVE attribute that is allocated in a subprogram called will need to be tracked by the runtime in case the subroutine is called inside a CHANGE TEAM construct. No suggestion for a change - just a heads up to implementors. Clause 6: I-6a) Including a MAX_COUNT specifier in an EVENT POST statement can lead to a race condition. It is possible to get around this with repeated retries with a compare-and-swap operation, but the implementation will be significantly slower than without the MAX_COUNT. I-6b) At m202, there was objection to the EVENT CLEAR statement on the grounds that it promoted race conditions (worse than other EVENT statements). A possible alternative is a EVENT WAIT (UNTIL_COUNT = ) form that would wait until the count got to the indicated level and then subtract the UNTIL_COUNT value from the event variable count. I-6c) The proposed COUNT= specifier for EVENT POST actually avoids race conditions and provides useful information that is otherwise available from EVENT_QUERY with a uncertainty because race conditions. This should be reconsidered. Clause 7: I-7a) In 7.4.11 EVENT_QUERY, the COUNT argument is assigned the value 0 if an error occurs. Not very informative. Perhaps count=-1 would be more useful in the error case. I-7b) In 7.4.11 EVENT_QUERY, if the STATUS argument is not present and an error condition occurs, does the program terminate? It appears not. That is the same as for GET_COMMAND and friends with a STATUS argument. But the opportunities for failure here are greater (EVENT image is failed, for example). Should a valid value be STAT_FAILED_IMAGE?