J3/16-176 To: J3 From: Malcolm Cohen Subject: Editor's TS report for 16-007r1 Date: 2016 May 02 0. Introduction This is the editor's report for applying the rest of the TS 18508, as modified by 16-156, to produce 16-007r1. There is a separate report (16-175) for applying the papers from meeting 209, which are also included in 16-007r1. I note that I exceeded my editorial licence and made a number of Technical Changes, clearly marked below as TECHNICAL CHANGE. These need to be reviewed (and modified if I got it wrong). There were many other places where the language in the TS simply said things that I thought were "obviously wrong". I corrected those editorially. Yes, some might have had "technical effect", but they are not marked as Technical Changes. There were a lot of changes made, and I think I remembered to note down all the significant ones and most of the insignificant ones, but given the sheer size of the editing involved, it is possible that I might have missed some out. i. Introduction Completely rewrote the submissions for this. The Introduction should probably be re-wordsmithed anyway. Unlike the interop TS, the coarray TS had wide-ranging effects across most clauses of the standard. It might be worth considering distributing its new features into the normal "new feature" bullets instead of collecting them together. It also might be worth considering whether any of the Technical Changes between the TS and the standard should be called out in the Introduction. (Assuming, that is, that they survive review!) 1. Clause 1 EXTRA EDIT: added CHANGE TEAM coselector associations to the definition of associate name, which the TS failed to do. "established coarray": REJECTED: qualifier "in a team": every image is "in a team" so this is no qualification at all. EDIT "a coindexed designator (ref)" -> "an \si{image-selector}". "active image": EDIT: reworded to simplify "image index": EXTRA EDIT added "within a \termi{team}" to the definition. collective subroutine: EXTRA EDIT: added term for "collective subroutine", since we have terms for the other classes of intrinsic procedure. "team": EDIT: rewrote to make it an ordered set (so that image index is more obvious) and to define by how it is formed, rather than vague waffle. "current team": REJECTED: qualifier "images". Yes, it only applies to images. That there is no other defined meaning means we don't have to qualify it. EDIT: reworded to avoid introducing the concept of "active" CHANGE TEAM constructs. "initial team": EDIT: reworded. "parent team": EDIT: reworded to use FORM TEAM (a singular occurrence for each team) rather than CHANGE TEAM (a multiple occurrence). Since teams are not created or destroyed by CHANGE TEAM, defining via CHANGE TEAM is inappropriate. Yes, CHANGE TEAM is (now) only allowed to specify a subteam of the current team, and therefore these would be equivalent, but why make the user wonder? EDIT: added qualifier since the initial team has no parent. reworded. 2. Clause 2 REJECTED: "A team of images is a set of images that can readily execute independently of other images.", because all sets of images possess that quality. REJECTED :"Syntax and semantics of \si{image-selector} are extended to determine how cosubscripts are mapped to image indices for sibling or ancestor team references." because it is: unimportant/irrelevant/immaterial/inappropriate. EDIT: I wrote some waffle, beginning "A team is...". EDIT: re team number, added "Within the parent team," since subteam numbers are only unique or indeed have any meaning within its parent team. EDIT: Reworded further. REJECTED: "Information about the team to which the current image belongs can be determined by the processor from the collective value of the team variables on the images of the team." because I have no clue what it is attempting to say (some of the obvious guesses look wrong!). REJECTED: "Executing a CHANGE TEAM statement ... END TEAM ..." as this does not belong here but in the statements in question. EDIT: I added some more waffle "Image indices, and thus coindexing of variable names with an \si{image-selector}, are relative to the current team unless...". Well, it looked like it was a good thing to say here. EDIT: "The value of an expression that include a reference to a coindexed object on a \termi{failed image} is processor dependent." ->"The value of a reference to a coindexed...", as I thought this was what we were agreed on. Otherwise we are at best in interp fodder land - so if anything different is wanted it will need to be spelled out precisely. BTW I did this everywhere, not just in this one place. Further occurrences will pass unremarked. EDIT: The text on atomic vs. failed images implied that ATOMIC_REF would act "safely" in its nonatomic definition. Obviously a mistake, so I reworded. Also this text directly contradicted what was stated elsewhere for lock variables, so I excluded them from this action. EDIT: Reworded the "corresponding coarray" text to simplify it. EDIT: Completely reworded the "established coarray" paragraph, I believe without technical change, and turned it into a new subclause. This new concept is tricky enough that I think it warrants a proper subclause of its own. COMMENT: Even so, the stablishment stuff is very hard to understand. REMARK: Nondummy nonallocatable coarrays are required to have the SAVE attribute, which means that they exist forever in all images of the program. So why are they not established except in the team that invoked a procedure or executed a BLOCK construct? One might have imagined that coarrays that are not established on an image need not exist on that image, but this is clearly wrong for saved nonallocatable ones. So I don't see what is gained by this extra complication. Maybe it would be easier to understand if we talked here (2.4.8) about what "establishment" means, at a higher level. All we have so far is a bunch of definitions and rules. 4. Clause 4 No comment. 6. Clause 6 TECHNICAL CHANGE: In the TS, the syntax of an image-selector requires the "image-selector-specs" to be in a particular order, unnecessarily, and unlike Every Other Specifier in the language. So I changed the syntax to make it like every other spec-list, i.e. any order will do. EDIT: There was something about "coarray designator", but there is no such thing, and it certainly cannot be the designator of a coarray since that would not be coindexed! Replaced with image-selector, and reworded. Similarly, the object is "the object" not "The coarray". Ended up with drastically rewording, as it was all too confusing. Hopefully I got it right... EDIT: "An image selector shall specify..." I moved this to follow the team specs, and nailed down that it is interpreted as the index in that team (it was unclear before). EDIT: Various places "these images" -> "those images". REMARK - "since execution last began in this team" does not appear to be well-defined! COMMENT: Re deallocation of coarrays, segment execution is delayed until the other images have executed "the same statement the same number of times since execution last began in this team". Passing over the ill-defined "last began", do we really mean the same statement? Obviously reasonable for DEALLOCATE, one might quibble about RETURN and END ("why do we have to GOTO 666 instead of just saying RETURN?"), but BLOCK can be completed in many ways - do we really require all images to exit the block with the same method (CYCLE/EXIT/GOTO/ENDBLOCK/...)? UTI: Added UTI 016. REJECTED: New paragraph at the end of STAT= in ALLOCATE/DEALLOCATE as it is trivially derivable from the fact that an image having failed is just as much an error as an image having stopped, if not more. I utterly reject the notion that we have STAT= nonzero indicating some kind of "success". 8. Clause 8 EDIT: In CHANGE TEAM construct, deleted contentfree misleading blather after "changes the current team". TECHNICAL CHANGE: In the END TEAM statement, the TS required there to be a sync-stat if the optional parens appeared. This is inconsistent with SYNC ALL, which permits empty parens. Changed the syntax to permit empty parens. EDIT: Constraint about branching out of CHANGE TEAM - deleted the unnecessary syntax rule qualification, added a cross-ref, now it looks the same as the constraint we have for CRITICAL. EDIT: Constraint about RETURN in CHANGE TEAM - deleted the unnecessary syntax rule qualification (sadly, the matching constraint in CRITICAL has the unnecessary qualification). DIFFERENT: Did not insert the constraint forbidding EXIT or CYCLE for an outer construct in CHANGE TEAM, instead, added CHANGE TEAM to the existing constraints in CYCLE and EXIT. TECHNICAL CHANGE: For consistency, forbade EXIT from belonging to a CHANGE TEAM construct, since we do that for CRITICAL. EDIT: Deleted unnecessary syntax quali in team-construct-name constraint. EDIT: In the other CHANGE TEAM statement constraint, deleted the syntax quali as it made the constraint harder to understand, and rewrote for clarity. EDIT: team-variable constraint, rewrote into appropriate and correct form. EDIT: coselector-name constraint, deleted unnecessary syntax quali, inserted necessary "given". EDIT: Last CHANGE TEAM constraint, "shall be the name of an accessible coarray"->"shall be a coarray". UTI: Added UTI 017. REJECTED: "Within a CHANGE TEAM construct, a coarray that is not an associating entity has the corank and cobounds that it had when it was established." as it would seem to be either unnecessary or insufficient. UTI: Added UTI 019. EDIT: Tried to rewrite the stuff about allocatables and CHANGE TEAM to improve clarity. UTI: Added UTI 020. DELETED: "The CHANGE TEAM and END TEAM statements are image control statements." - we never say this of the others. REMARK: Another "when execution last began". This phrase needs to go. REJECTED: TS says the critical construct only limits to one image in the current team at a time. Some mistkae shurely. If it is unsafe for two images from the current team to be inside at the same time, it is almost certainly unsafe for two images from different teams to be inside at the same time. Left at only one image (thus in the whole program) at a time. TECHNICAL CHANGE: Added parentheses around the sync-stat-list in CRITICAL; actually the parenthese do appear elsewhere in the TS, just not in the edits. Also, permit them to be empty, just like SYNC ALL. EDIT: In CRITICAL construct added cross-ref to {D2:Image execution states} for image failure. REMARK: I suppose we really wanted to require image failure to release CRITICAL locks, but it sounds like it could reduce performance of CRITICAL in all programs whether they want image failure handling or not. EDIT: Rewords the "effect of STAT= ..." in CRITICAL. EDIT: In FAIL IMAGE statement, reworded "behave as if it had failed" to say what that really means. EDIT: added a note to the NOTE to say that FAIL IMAGE is not an image control statement. From the name, a naive reader might well assume that it is (without checking). EDIT: Image control statement list, reworded new entries and put into more obvious places. EDIT "atomic subroutine" was partially indexed under "subroutine!atomic"; I made this more consistent. REMARK: SYNC ALL statement, again with the ill-defined "last began". I wonder whether a simple count, e.g. ``a SYNC ALL statement for this team'' is sufficient for this case? UTI: Added UTI 022. UTI: Added UTI 023. DELETED: "The SYNC TEAM statement is an image control statement." DID NOT INSERT (16-156): "The values of the team-variables on the active images of the team shall all represent the same team." as this lacks sufficient context to tell when it is being required. Anyway it ought to come out of the semantic effects... as far as I can tell, if they are not the same then they just don't synchronize, so what's the problem? REMARK: Obviously the specified team needs to include the executing image. If team variables went undefined when copied across images we would have this for free, but... that does not happen. IMPORTANT: This needs to be said, right? EDIT: Between "Successful execution of a SYNC TEAM statement performs a synchronization" and "of the team specified by \si{team-variable}", deleted "of the executing image with each of the other active images", as this is just muddying the waters. Hopefully this will get sorted out as required when UTI 024 is resolved. UTI: Added UTI 024. EDIT: Simplified the NOTE at the end of SYNC TEAM. EDIT: In form-team-spec constraint, deleted unnecessary syntax quali, inserted necessary "given". EDIT: Paragraph about when NEW_INDEX= does not appear, massive rewrite to straighten out grammar etc.. REMARK: "Failure of an image causes all lock variables that are locked by that image to become unlocked." sounds expensive. Sounds like as soon as the image is known to have failed we need to unlock the variables. I understand that this is desirable behaviour, but should that have been "eventually" unlocked? MISSING EDIT: The sentence in 8.6.10 LOCK and UNLOCK statements, p5 "During execution of the program, the value of a lock variable changes through a sequence of locked and unlocked states due to the execution of LOCK and UNLOCK statements." is no longer accurate. ***I DID NOT FIX THIS***. It does need to be fixed. UTI: Added UTI 025. 13. Clause 13 REMARK: The opening sentence of 13.6 "A collective subroutine is one that is invoked on each active image of the current team to perform a calculation on those images and that assigns the computed value on one or all of them." seems too vague to be useful, but I left it in. Can we not have a better introductory waffle sentence? TECHNICAL CHANGE: The requirement in the TS "A call to a collective subroutine shall appear only in a context that allows an image control statement." is a Syntactic Requirement. We ALWAYS have syntactic requirements written either directly as syntax rules, or as constraints. So I made it into a constraint. REMARK: Perhaps we should note that "A reference to a collective subroutine is not an image control statement."? Or "Even though the calculations performed by collective subroutines have some internal synchronizations, a reference to a collective subroutine does not synchronize the involved images and is not an image control statement."? UTI: Inserted UTI 026. REMARK: I was wondering whether STAT_STOPPED_IMAGE and STAT_FAILED_IMAGE should make the "A" argument become undefined, or whether this was supposed to be detected before it got run over. REMARK: I was also wondering why the A argument would become undefined in CO_BROADCAST, since it is not updated on SOURCE_IMAGE. REMARK: 13.6p7 could I think do with a bit more wordsmithing, to clarify that "any other error" should take precedence over STAT_STOPPED_IMAGE and STAT_FAILED_IMAGE? STOPPED>FAILED is clear enough already. UTI: Inserted UTI 027. DELETED: Second NOTE at the end of 13.6 Collective subroutines, as it was completely uninteresting. Everyone already knows how to make a copy of some data. DELETED: Third NOTE at the end of 13.6, as it was too handwavy, too vague, and seemed to be possibly incorrect. If there is anything worth preserving in the note, please reduce the waffle (which was at best misleading) before resubmitting. (I did not see anything of significant value in the note, but...). EDIT: CO_BROADCAST, inserted "active" in several places otherwise stopped or failed images cause program nonconformance instead of raising an error condition. Also inserted "in corresponding references" in places so that the cross-image requirements only apply to such references, not permanently and continuously! EDIT: Similarly in the other collectives. EDIT: CO_SUM, deleted "If RESULT_IMAGE is present, the computed value may depend on the image that RESULT_IMAGE specifies; otherwise, the computed value is the same on all images in the current team." as the former is implied by "processor dependent" and the latter is implied by "the computed value". UTI: Inserted UTI 028. EDIT: FAILED_IMAGES, deleted "and has not meanwhile entered or left a CHANGE TEAM construct," because how can that make a difference, especially when the team being sunc or inquired about need not be the current team anyway? EDIT: IMAGE_INDEX, reworded the descriptions of the arguments. POSSIBLE TECHNICAL CHANGE: Those descriptions were reworded to be what I thought the TS was trying, unsuccessfully, to say. I think I got it right, but I might have gotten it wrong. REMARK: IMAGE_INDEX, the result value description is far from obviously correct. But I'm too tired to figure it out. Should probably be wordsmithed to make it easier to understand. TECHNICAL EFFECT: IMAGE_STATUS, added the obvious requirement that IMAGE be positive and less than or equal to the number of images in the specified team. UTI: Added UTI 030. EDIT: MOVE_ALLOC, reworded nonsense (STAT= specifier forsooth). EDIT reworded more... Obviously if this only affects the active images, as it says above, there Can Be No Interaction with a stopped image! EDIT: STOPPED_IMAGES, Result Value, inserted "are known to have". We are not in a single timestream here. DELETED "and has not meanwhile entered or left a CHANGE TEAM construct,"; as for FAILED_IMAGES this would seem to be irrelevant. EDIT inserted "shall be known to have". UTI: Inserted UTI 029 (THIS_IMAGE). EDIT: THIS_IMAGE, instead of inserting new cases, merged the new parts into the old parts, which were wrong anyway without any specification of the team for the image index (current team or initial team or what team?). EDIT: UCOBOUND, Result Value, reworded. EDIT: STAT_FAILED_IMAGE, reworded. If the processor does not support failed images we don't need weasel words to avoid things, it is simply that images never "fail" (with the meaning here) on such a processor. DELETED "If more than one nonzero status value is valid for the execution of a statement, the status variable is defined with a value other than STAT_FAILED_IMAGE." since we just said that STAT_FAILED_IMAGE was NOT valid if another error condition occurs! REMARK: The design that STAT_FAILED_IMAGE does "all the successful things" is a distinctly suboptimal and confusing design. It would seem to be incompatible with F2008 error handling. It is certainly an unnecessary thing to do, and since the obvious response to this error is to immediately redefine the team to exclude the failed images, could result in more convoluted and slower programs. E.g. you might need to allocate bigger arrays if there are suddenly fewer images to spread the work over. REMARK: STAT_STOPPED_IMAGES, I left the text to require synchronization, but it is obviously wrong given the current wording of the collective subroutines, see UTI 027. DELETED: I declined to enter the unnecessary and unwarranted advertisement for the STOPPED_IMAGES intrinsic, which is not even the only other way of discovering which images are stopped. TECHNICAL CHANGE: Since the TS envisages accessing TEAM_TYPE variables as coarrays, no component can be a pointer lest it become undefined on cross-image assignment. So I put that in. DELETED "A scalar variable of this type describes a team." since the initial value does not. EDIT: Statement and construct entities, added corank to the things the associate name of CHANGE TEAM gets from the coselector. EDIT: Events that cause variables to become defined, "become unlocked" -> "become defined" cf UNLOCK item above. It needs to say what that state is elsewhere anyway (and I seem to recall that it does). EDIT: Image failure causing variables to become undefined, as earlier, excluded lock variables from this to avoid contradiction (they become unlocked, not undefined!), also it is only the ATOM that acts atomically and thus safely. EDIT: Variable definition context, the TS edits seem to be somewhat confused, so I rewrote. I think I got it straightened out. I did not check other places to see whether similar confusions existed. A. Annex A EDIT: conditions that cause an image to fail, cross-reffed to "Image execution states" in clause 2, not to 13.9.2.21b !!! DELETED: processor dependency for IMAGE_STATUS since it is based on nonsense (see UTI 030). C. Annex C EDIT: Accessing coarrays in sibling teams, converted example to monocase instead of a mixture of camelcase (ugh!) and inconsistent casing (double ugh!). EDIT: Reducing the codimension of a coarray, I started to try to straighten out the example, e.g. Q is set to "..." and never ever used, thus illustrating nothing, NA should have been something like PROBLEM_SIZE (removing a silly comment), and in general there were far too many "...". DELETED the entire example as having no meat and too few bones to even be a skeleton. As was, it illustrates virtually nothing. I do not believe people need an example of this (it is obvious already), but if they do need one, it needs to be a lot better than this. EDIT: Example involving failed images, (1) example had inconsistent casing. Converted to use uppercase for all keywords and intrinsic features. (2) gave an actual formula for the number of spare images, instead of just "..."; the closer the example is to something that can actually be compiled and run, the better! EDIT: "fail-safe" does not have the same meaning as "fault-tolerant". Used the latter which is what I believe was intended. ===END===