13-296 From: Bill Long To: J3 Date: 3 July 2013 Subject: Issues arising during creation of 13-293 References: 13-293 Description: ============ During the construction of 13-293 (N1983) some issues were noted that were outside the bounds of editorial fixes. Those are recorded in this paper. Page and line numbers are relative to 13-293. Issues: ======= Clause 5 Teams of images ------------------------ I1: [9:22-29] The reason for disallowing the POINTER attribute for a variable with a subobject of type TEAM_TYPE should be documented, with explanation of why it is not a requirement for a variable of type TEAM_TYPE. I2: [9:22-29, 13:15-22] We now have very similar sets of constraints for variables of type LOCK_TYPE, TEAM_TYPE, and EVENT_TYPE. The basic reason is the same in all cases - the desire to restrict definition of such variables to a limited set of statements. Perhaps constraints for a new concept, such as "restricted type" or "restricted-use type" could be written once and then referenced for the three cases. I3: [10:29] The new syntax for image selectors needs illustrative examples. A Note at the end of 5.4 [10:32+] would be good; at least an example in the Annex. I4: [11:1] The new syntax to allow a team member to choose an image index value needs illustrative examples. A Note at the end of 5.5 [11:17+] would be good; at least an example in the Annex. I5: [12:4+] Would it be useful to have another Note that says failure of image 1 of the initial team of images is particularly problematic because of the lost connection to standard input? Clause 6 Events --------------- I6: [13:29+] In the new Atomic subroutines section we say that "How sequences of atomic actions in unordered segments interleave with each other is processor dependent." That text is copied from F2008. Should we have a similar statement about event posts, since they are similar to atomic operations? Clause 7 Intrinsic procedures ----------------------------- I7: [15:15-16] In the case of an optional OLD argument to an atomic subroutine, the code generated is different depending on whether OLD is present or not. This is a side effect of economizing on subroutine names by using the same name for two operations. If the user writes an OLD argument into the call, it will almost always be the case that it will be referenced soon after the call. We should probably say that and optional OLD argument that appears shall be present. I8: [15:32-34] The first sentence of paragraph 5 in 7.3 says that a failed execution of a collective is the same as SYNC MEMORY which has the effect of making it an image control statement. But a successful execution is not an image control statement. This is not consistent. The end of the sentence "and the effect...SYNC MEMORY statement" should be deleted. I9: [15:38-39] The last sentence of the same paragraph says "..an image had failed..". It is unclear what images count here. Any one from the initial team, or just ones in the current team (and hence involved with the call)? Probably intend the current team, but it should be clarified. I10: [19:37] In the description of the OPERATOR argument to CO_REDUCE we say that the operation is commutative, but fail to say is is associative. That should be added. Clause 8 Required editorial changes to ISO/IEC 1539-1:2010(E) ------------------------------------------------------------- I11: [26:38+] In Note 4.48 in 4.5.6.2 The finalization process of 10-007r1, we might need to add "in the current team" at the end and consider rewording to avoid the word "event". This would require a new subclause in the TS: Edits to clause 4. I12: [27:22+] We need an edit for the STAT= description in 6.7.4 similar to the new text in [28:28-36] to account for "current team" and also STAT_FAILED_IMAGE. I13: [27:27+] Does the exclusive execution of a CRITICAL construct apply to all images of the initial team of images, or just the current team? Probably the initial set (because it is usually use to protect a global resource), but that should be clarified. I14: [28:25,28,38] The new text in the edits for 8.5.7 includes the case of a STAT= specifier appearing on an END TEAM statement, but there is no syntax for that. Note that the text at [28:23-24] contains the "as an appearance both there and in the corresponding END TEAM". This text has various ambiguities and needs to be fixed, or specific syntax added for END TEAM. I15: [28:22-29:3] For the STAT= edits, there is no mention of EVENT POST or EVENT WAIT. Both of these statements have optional STAT=. I16: [30:4-9] In the table entries for intrinsics we refer to "all images" 5 times in reference to collectives. This needs the "current team" fix. Or just say "across images". ==END==