(j3.2006) (SC22WG5.5211) [Ballot on draft DTS]

[Van Snyder]

On Wed, 12 Mar 2014 15:44:11 +0000 John Reid <John.Reid at stfc.ac.uk>
wrote

This is a WG5 letter ballot on N2007, the fourth draft DTS for 
TS 18508, Additional Parallel Features in Fortran.

N2007 has the same content as J3/14-130. It was prepared by the editor, 
Bill Long, following the recent meeting of J3. Details of the changes 
made from the previous draft, N1996, are given in J3/14-134.txt. 

Please answer the following question "Is N2007 ready for forwarding to 
SC22 as the DTS?" in one of these ways. 

1) Yes.
2) Yes, but I recommend the following changes. 
3) No, for the following reasons.
4) Abstain.

This is an individual vote. Please send your vote to
sc22wg5 at open-std.org 
to arrive by 9 a.m. (UK time) on 16 April 2014. 

As I began reviewing N2007/14-130, I expected to vote "Yes, but I
recommend the following changes."  After the first day of review, I
decided I ought to proofread my comment before sending it.  I found a
few things I wanted to add.  The next day, and the next, ... and for
three weeks, I kept finding things.  Now that the comment exceeds 600
lines, and I no longer have time to proofread it again, I find it
necessary to vote "No, for the following reasons."

The attachment is a bit of "stream of consciousness" rambling, but I
have run out of time to organize it further."

-------------- next part --------------
Comments fall into three categories:

1. Stuff that might be profitably added.

2. Stuff I would do differently.

3. Other stuff

Stuff that might be profitably added
====================================

It is processor dependent whether common or independent random number
generators are used, and there's no way to detect which is the
situation.  Therefore taking action using one assumption or the other
(e.g., calling or not calling RANDOM_SEED on each image with a
hopefully-different value, maybe dependent on the image number) might be
the wrong thing to do.  It is preferable to provide a named constant in
ISO_FORTRAN_ENV to indicate whether the processor uses a common random
number generator on all images, or intrinsic procedures so to inquire or
specify.  References to the intrinsic subroutine that specifies whether
common or independent random number generators are used should be image
control statements.  13.5p4 should be adjusted so that the segment
ordering requirement applies only if a common random number generator is
used.

Note 5.8 suggests that there ought to be a mechanism to specify, change,
and inquire the image to which standard input is connected.  The OPEN
and INQUIRE statements come immediately to mind.  The image index should
be in the initial team, and connecting should, for consistency, be
allowed in only one image.  Either that, or standard input should be
connected to all images.  A READ statement for a file that is attached
to more than one image should be specified to execute as if in a
critical section.

A pointer can have a coarray target, but cannot be directly coindexed,
although if they're actual arguments associated with (necessarily
nonpointer, so far) coarray dummy arguments, their target can be
coindexed in the invoked procedure.  Allow coarrays to be pointers. 
Prohibit allocating and deallocating coarray pointers.  In pointer
assignment, require that if the pointer is a coarray, the data target
shall be a coarray.

Stuff I would do differently
============================

[12:6] It's a bit easier to compute team numbers if zero is allowed. 
E.g., mod(this_image,4).  Replace "be greater than zero" with "not be
negative" and replace "1" with "zero" at [26:6]

[15:14-15] It would be better if variables of EVENT_TYPE were not
required to be coarrays.  Instead eliminate C601 and constrain
<event-variable> to be a coarray, a coindexed object, or a pointer in
C604, and a coarray or a pointer in C605.  In pointer assignment, if a
<data-pointer-object> is of type EVENT_TYPE, or of a type that has a
noncoarray potential subobject component of type EVENT_TYPE, constrain
the <data-target> to be a coarray or a pointer.  Thereby, by induction,
a EVENT_TYPE pointer can only be associated with a coarray.  14-138
advocates the same for LOCK_TYPE.

[15:16-24 C602, C603] Protected types would be a better solution.

If EVENT_TYPE were a protected type, or by adding

"C602a A subobject of an event variable shall not appear in a variable
       definition context, shall not be an actual argument in a
       reference to a procedure with implicit interface, and shall not
       be an actual argument associated with a dummy argument that has
       unspecified intent."

at [15:24+], it would be possible to expose the event count as a
specific component name, and eliminate EVENT_QUERY.

Since we have decided that we do not want to allow type-bound procedures
to be actual arguments or procedure pointer targets, we could allow to
invoke type-bound functions that have no arguments without parentheses
enclosing the (empty) argument list.  A corresponding change should
allow to reference a scalar with an empty subscript list.  Thereby, it
would be impossible to know, and impossible for the syntax to depend
upon, whether event%count or event%count() is a reference to a scalar
component or a type-bound function that has no arguments.  This is
intended as food for future thought; it's outside the scope of the
present TS.

If protected types existed, LOCK_TYPE should also be a protected type.

[17:24-25] Since references to collective subroutines have to be invoked
by the same statement on all nonfailed images of the current team, and
it's hard to imagine how they can produce an output argument value
that's the result of a collective action until all of them finish, it
would be simpler either to make references to them be image control
statements (and establish segment boundaries), or to specify that
executing them includes the effect of executing an image control
statement.  (This is done by the edit proposed for [32:21+] below.) 
This would also affect the discussion at [47:15-16].

[18:11ff General for 7.4.2, 7.4.4 and 7.4.5] Since intrinsic procedures
are "magic" it would be possible (and more economical) to replace
ATOMIC_AND, ATOMIC_OR and ATOMIC_XOR with ATOMIC_OP ( ATOM, OPERATOR,
VALUE ) or ATOMIC_OP ( ATOM, OPERATOR, VALUE, OLD ), and require
OPERATOR to be a local name for one of the intrinsic functions IAND,
IEOR or IOR.  Yes, this is an exception to the general rule that generic
names cannot be actual arguments, but so what?  Intrinsics are magic.

[18:30ff General for 7.4.7, 7.4.8] Since intrinsic procedures are
"magic" it would be possible (and more economical) to delete CO_MAX and
CO_MIN in favor of CO_REDUCE, and allow the OPERATOR of CO_REDUCE to be
a local name for one of the intrinsic functions MAX or MIN.  It would be
nice to include PRODUCT and SUM under this rubric, but they don't have
two arguments, so explanation of CO_REDUCE might become difficult.  Yes,
this is an exception to the general rule that generic names cannot be
actual arguments, but so what?  Intrinsics are magic.

[24:20-25:20]  Since TEAM_TYPE is not prohibited in a variable
definition context, GET_TEAM could be a function instead of a
subroutine.  This would be handy for passing team variables as actual
arguments.

[32:21+] Insert "{In 8.5.1 Image control statements, insert a list item}
'a CALL statement that references an intrinsic collective subroutine'".

Other stuff
===========

[General] Turn on paragraph numbering.

[General] Process with LaTeX such that ligatures are not used.  This
makes words that contain, e.g., "fi", searchable in Acrobat Reader.

[General] Use either "in the current team" or "of the current team", and
either "in the initial team" or "of the initial team", throughout, not
one or the other at random.  Using "in" might make more sense since
"image of the current team" need not necessarily be read as "image that
is a member of the current team."  It might be read as if there is,
somehow, an "image" (with a meaning different from the one in Subclause
2.3.4 of 1539-1, e.g., "a photograph", or a copy -- "image" --  of the
team variable), that reflects or represents all of the current team.

[General] "positive" appears in some places, while "greater than zero"
appears in other places.  Use "positive" throughout (because it's
shorter).

[General] "less than or equal to" appears in some places, while "not
greater than" appears in other places.  Use "not greater than"
throughout (because it's shorter).

[Foreword iii:p5:line 3] Is "must" the correct word here?

[Introduction iv:p1:2] Delete "a set of".

[Introduction iv:p2:6] Delete "for".

[Introduction iv:p2:8] Replace "progress" with "proceed" because
"progress" does not appear anywhere else, except in notes, in either the
TS or 14-007.  Either that, or define "progress" (as a verb) in the
"Terms and definitions" subclause.

[Introduction iv:p3:5] Delete "sets of".

[9:26-30] Should TEAM_TYPE be specified to have a public type-bound
defined assignment?  Or does it not matter because one cannot tell the
difference?

[10:7 C503] Replace "A" with "An".

[10:13 C505] After "<coselector-name>" insert ", or the same as a
<coarray-name> in another <codimension-decl>,".

[10:31-34] Raises the question whether allocatable non-coarray variables
that are not allocated at the beginning of a CHANGE TEAM construct are
deallocated at the end.  Probably not.  If yes, it should be specified. 
If not, it should be mentioned in a note.

[10:36] The phrase "team containing the executing image that is
identified by <team-variable>" should almost certainly be "current
team".  I don't see how things can be otherwise.  If some subset of the
current team decide they're going to be in one subteam, and only those
images execute the CHANGE TEAM statement, from the point of view of
other images of the (previously) current team, the images of that
subteam are still part of their team; the result is overlapping teams,
until other images, that are members of other teams, execute a different
CHANGE TEAM statement, maybe in an unordered segment.  I thought the
intent of the CHANGE TEAM construct was to partition the current team,
so that no image can ever be a member of more than one
currently-executing team.  In any case, the phrase "executing image that
is identified by <team-variable>" appears to be nonsense.  A
<team-variable> identifies a set of images, not one image.  I don't see
a clean way to reorganize the sentence to make it clear that
"<team-variable> applies to "the team", not "the executing image".

[12:6-7] Replace "be greater than zero and is the same for all images
that are members of the same team" with "be positive.  Images are
members of the same team if and only if they specify the same value of
<team-id>."  (I prefer "not be negative" instead of "be positive".  It's
a bit easier to compute team numbers if zero is allowed.  See the remark
for [12:6] in the "Stuff I would do differently" section above.)

[12:12] Replace "assigned by the processor" with "a processor dependent
value that shall be positive and not greater than the number of images
in the team".

[13:Note 5.6] There are assumptions about RANDOM_NUMBER here.  If all
images produce exactly the same sequence of random numbers, they will
all fail, pretty much at the same time.  Maybe insert something to the
effect "if the random number generators on different images are
independent and are started with seeds that produce different sequences,
or a common random number generator is used...."

[13:20] Replace "defined" with "declared".

[14:Note 5.8] Replace "image 1" with "image 1 in the initial team"
twice. 

[15:7] Append "It does not have the BIND attribute, and is not a
sequence type."

[15:9-10] Replace "The effect of each change ... change" with "The event
count is updated as if by invoking the ATOMIC_ADD intrinsic subroutine"
to avoid any suspicion that a new kind of mechanism is in play here.

[15:16] Replace "An" with "A nonpointer".

[15:19,24] Replace "where" with "if" twice.

[15:21] Insert "nonpointer" before "variable".

{It would be better to append "unless both the actual argument and dummy
argument are pointers" at the end of 16.6.7p1(12), but that ought to be
done in the normal course of a revision, not sneaked in via a TS.}

[15:24+] Insert a constraint
  "C603a (R425) If EXTENDS appears and the type defined has a potential
     subobject component of type EVENT_TYPE from the intrinsic module
     ISO_FORTRAN_ENV, its parent type either shall be EVENT_TYPE or
     shall have a potential subobject component of type EVENT_TYPE."

This is actually undesirable to put in the standard.  What we really
want to do is to combine the protection of EVENT_TYPE and LOCK_TYPE from
by polymorphism, so that one could extend EVENT_TYPE and give a
component of LOCK_TYPE and vice-versa; therefore to re-write C435 to say

C435 (R425) If EXTENDS appears and the type defined has a potential
     subobject component of type EVENT_TYPE or LOCK_TYPE, from the
     intrinsic module ISO_FORTRAN_ENV, its parent type either shall be
     EVENT_TYPE or LOCK_TYPE, or shall have a potential subobject
     component of type EVENT_TYPE or LOCK_TYPE.

[15:24+] Insert a paragraph

"The value of the actual argument corresponding to the CPTR argument of
the C_F_POINTER subroutine from the ISO_C_BINDING intrinsic module shall
not be the address of an object of type EVENT_TYPE, unless the FPTR
argument is a pointer of the same type as the object."

[15:24+] Note 13.29 in 14-007, concerning lock variables, was apparently
considered to be useful.  Insert a similar note concerning event
variables:

  "Note 6.0
     The restrictions against changing an event variable except via
     EVENT POST and EVENT WAIT statements ensure the integrity of its
     value and facilitate efficient implementation, particularly when
     special synchronization is needed for correct event handling."

[15:26, 30-31] Replace the introductory paragraph with

  "Successful execution of an EVENT POST statement posts an event,
   consisting of atomically incrementing the count of the event variable
   by 1.  If an error condition occurs during execution of an EVENT POST
   statement, the count does not change.  The EVENT POST statement is an
   image control statement."

Then delete the paragraph immediately after C604.

Using "atomically" here is important.  Either that, or it is necessary
to say that an EVENT POST statement executes as if in a critical
section.

[15:29] Delete "the".

[16:1-16] Notwithstanding "the effect of each change is as if it
occurred instantaneously" at [15:8-9], it seems to be necessary to say
that steps (2) and (3) of the EVENT WAIT statement execute as if in a
critical section, because testing its value isn't part of "each change
... occurred instantaneously."  Otherwise, if two images execute EVENT
WAIT statements, when another image posts an event, it is possible that
both of them notice the threshold is exceeded, both stop waiting, and both
reduce the event count, the result being that the event count becomes
negative.  Indeed, it might be necessary to say this about some other
image control statements, at least ALLOCATE, DEALLOCATE, and calls to
MOVE_ALLOC.  If so, can it be done here, or is an interp needed?

[16:2] Replace the introductory paragraph with

  "Successful execution of an EVENT WAIT statement waits until a
   specified number of events are posted by successful execution of
   EVENT POST statements.  The EVENT WAIT statement is an image control
   statement."

[16:8] Replace "threshold of its event argument" with "threshold value". 
Otherwise, "threshold value" in the next two steps is not a defined
concept.  Don't use "argument" since the EVENT WAIT statement is not a
procedure reference.

[16:12] Replace "event count" with "count of the event variable", for
consistency with [15:30] and [16:10].

[17:32] Delete first "the".

[17:33] Replace "on" with "in".

[17:38] Insert "processor-dependent" before "nonzero".  Should there be
a requirement that the nonzero value be different from
STAT_STOPPED_IMAGE or STAT_FAILED_IMAGE?

[18:1] Insert "the named constant" before "STAT_STOPPED_IMAGE" and
replace "in" with "from".

[18:3] Insert "the named constant" before "STAT_FAILED_IMAGE" and
replace "in" with "from".

[18:4] Replace "as" with "to be" or "to have".

[18:10+ Note 7.1] I can't figure out the point of the note.  If it isn't
pointless, replace "undefined ... collective with RESULT" with
"undefined if an error condition occurs during execution of a collective
subroutine and the RESULT argument is".

[18:16 19:2] Delete "and" twice.

[19:9-11] Can we put the argument value conditions first?  For example
"CALL ATOMIC_AND ( I[3], 6, IOLD ) with the value of I[3] equal to 5
causes...."

[19:16 19:34] Delete "and" twice.

[19:41-43] Can we put the argument value conditions first?

[20:5] Delete "and".

[20:1 20:12 34:14+9] Perhaps ATOMIC_XOR should be ATOMIC_EOR since the
intrinsic function it says it uses "under the covers" is IEOR.

[20:7] Repair the typesetting so the line doesn't end with left
parenthesis.

[20:12-14] Can we put the argument value conditions first?

[20:19-22] The SOURCE argument to CO_REDUCE is prohibited to be
polymorphic. Can the SOURCE argument to CO_BROADCAST be polymorphic?  If
so, insert "dynamic" before "type" and replace "parameters" with
"parameter values" (the parameters are necessarily the same on all
images, because all images execute the same statement).  If not, replace
the sentence with "shall be a scalar or array of any type.  It shall not
be polymorphic.  Each length parameter shall have the same value on all
images of the current team."  The first paragraph of 7.3 requires the
subroutine to be invoked by the same statement on all images of the
current team, and therefore the declared type and kind type parameter
values cannot be different.

[19:22] Append "It is an INTENT(INOUT) argument."  The associated actual
argument cannot be an expression because all images execute the same
statement, and a new value is assigned on all but SOURCE_IMAGE.  This
cannot be done for CO_MAX etc., for reasons already explained by Nick.

[20:34-35] Delete "It shall have... team." because it cannot be
otherwise.

[20:40,41] Either replace "RESULT" with "it" at line 40, or replace "It"
with "RESULT_IMAGE" at line 41.

[21:5] Delete "the" before "images".

[21:7, 21:34, 23:15] Is it really necessary for SOURCE to become
undefined on images other than RESULT_IMAGE if RESULT is not present? 
Why not simply "unchanged"?

[21:20-21] Delete "It shall have... team." because it cannot be
otherwise.

[21:26-27] Either replace "RESULT" with "it" at line 26, or replace "It"
with "RESULT_IMAGE" at line 27.

[21:32] Delete "the" before "images".

[22:1-2] ER-RMSG is strange hyphenation.  If it doesn't fit if
hyphenated ERR-MSG, put it all on the next line.

[22:6-7] Delete "It shall have... team." because it cannot be
otherwise.

[22:17,19] Either replace "RESULT" with "it" at line 17, or replace "It"
with "RESULT_IMAGE" at line 19.

[22:44-23:1] Delete "It shall have... team." because it cannot be
otherwise.

[23:7-8] Either replace "RESULT" with "it" at line 7, or replace "It"
with "RESULT_IMAGE" at line 8.

[23:13] Delete "the" before "images".

[23:24-24:1]  Since EVENT_QUERY almost certainly internally consists
only of looking at a component of a coindexed object, why does it have
STAT and ERRMSG arguments?  A reference to a coindexed object in, say,
an expression, doesn't have them.  It would be simpler if EVENT_QUERY
were a function, maybe better as a type-bound function than an intrinsic
function.  Even better would be if EVENT_TYPE were a protected type and
COUNT were a public component.

[23:30] Replace "no" with "not".

[23:32] Subtracting one for each successfully-executed EVENT WAIT
statement doesn't account for the UNTIL_COUNT specifier in the EVENT
WAIT statement.  But why specify the computation here (again)?  Replace
"number of successful posts minus the number of successful waits" with
"the event count of the EVENT argument".

[23:35] Replace "defined" with "dependent".

[25:36] Is it possible for EVENT_QUERY to set STAT to STAT_STOPPED_IMAGE
or STAT_FAILED_IMAGE?  Even if not, should there be a requirement that
the error status be different from those values (at least to
future-proof it)?

[24:10] Insert "decimal" before "range".  Replace "be at least as large
as" with "not be less than that" (for consistency with [23:30]).

[26:6] Replace "1" with "zero" if it is decided that team numbers can
begin at zero (see the edit above for [12:6-7] and the remark for [12:6]
in the "Stuff I would do differently" section above).

[26:40] Insert "processor-dependent" before "nonzero".  Should there be
a requirement that the nonzero value be different from
STAT_STOPPED_IMAGE or STAT_FAILED_IMAGE (at least to future-proof it)?

[27:12,14] After "present" insert "or is present with the value false",
then delete ", otherwise ... specified".

[29:9] Replace "a" with "as".

[29:16] Replace "it" with "the subset" to avoid confusion with "it"
meaning "the program".

[29:21] Insert "for" before "performing".

[29:23] Replace "features for the support of" with "facilities to
support".

[29:24] Replace "features" with "facilities".

[30:11] After "team" insert ", consisting of all images,"

[31:2] Is it necessary or useful to mention access to images of other
teams here?

[31:13] Insert a comma after "appears".

[33:35-32:5] Are these the only possible nonzero values?  If not, add a
sentence about any other errors resulting in a processor-dependent
positive value different from STAT_....

[31:37] Replace "in" with "from" for consistency with 6.7.4 etc.

[32:1] Replace "in" with "from".

[32:4] Replace "in" with "from".

[32:5] Insert "allocation" before "status".

[32:36] Delete "that is".

[33:17-25] Are these the only possible nonzero values?  If not, add a
sentence about any other errors resulting in a processor-dependent
positive value different from STAT_....

[33:20,21,24] Replace "in the intrinsic" with "from the intrinsic"
thrice.

[33:37+] Insert a new subclause
"8.7a Edits to Clause 9

{In subclause 9.5.1, paragraph 4, concerning an asterisk in a READ
statement, insert 'in the initial team' after 'image 1'.}"

[34:7+] Insert "{In Note 13.1 replace 'atomic variables' with 'access to
variables using atomic subroutines'}" because Fortran does not have
atomic variables, and the term is not used anywhere else.

[34:19+] Insert "{In subclause 13.5, paragraph 3, insert 'in the initial
team' after 'image 1'}."  [In a separate J3 paper, I advocate that the
kinds of specific discussions in 13.5p3-6 ought to be in the individual
procedure descriptions, not in 13.5.]

[34:19+] Insert "{In subclause 13.5, paragraph 4, replace 'the
interleaving of calls to RANDOM_NUMBER' with 'the sequences of values
assigned to the HARVEST argument to RANDOM_NUMBER'}." because the
interleaving of calls to all subroutines in unordered segments is
processor dependent (although a standard-comforming program cannot
observe that), so what's currently in 13.5p4 doesn't say much of
anything.

[35:24-26] After "present" insert "or is present with the value false",
then delete ", otherwise ... specified".

[36:6-7] Replace "and" with a comma.  At the end of the sentence append
", and the final normative paragraph" [the one added above by the edit
at [15:24+].

[36:7+] Insert "{In 13.8.2.16 LOCK_TYPE, in constraints C1303 and
C1404, replace 'where' with 'if' twice.}".

[36:9] If "5.6" is not generated by \ref, replace "5.6" with "5.8".  If
it is, check the \ref, and either repair it or run LaTeX a few more
times.

[36:9+] Subclause 5.8 requires the value of STAT_FAILED_IMAGE to be
different from the values of STAT_STOPPED_IMAGE, STAT_LOCKED,
STAT_LOCKED_OTHER_IMAGE and STAT_LOCKED, but there are no requirements
on the values of the latter constants other than the existing
requirement that the value of STAT_STOPPED_IMAGE be different from the
value of IOSTAT_INQUIRE_INTERNAL_UNIT.  Should that be corrected here,
or in the normal course of revising the base standard?  If the latter,
the TS would need to anticipate the revision and amend it.  Therefore,
rather than putting the requirements from subclause 5.8 of the TS in a
new subclause 13.8.2.21b, append a new subclause 13.8.26 "Uniqueness of
values of named constants" with text something like "The values of the
named constants IOSTAT_INQUIRE_INTERNAL_UNIT, STAT_FAILED_IMAGE,
STAT_LOCKED, STAT_LOCKED_OTHER_IMAGE, STAT_STOPPED_IMAGE, and
STAT_UNLOCKED shall be distinct."

[36:11+] Insert "{In C1303 in 13.8.2.16, insert 'in an ALLOCATE
statement without a SOURCE= specifier, as an <allocate-object> in a
DEALLOCATE statement' after '<allocate-object>'.}"

Insert "{In C1304 in 13.8.2.16, insert 'in an ALLOCATE statement without
a SOURCE= specifier, as an <allocate-object> in a DEALLOCATE statement,'
after '<allocate-object>'.}"

Insert "{In 13.8.2.16 insert a paragraph

'The value of the actual argument associated with the CPTR argument of
the C_F_POINTER subroutine from the ISO_C_BINDING intrinsic module shall
not be the address of a variable of type LOCK_TYPE, unless the FPTR
argument is a pointer of the same type as the object.'
}"

[36:11+] Insert a subclause 8.9a Edits to clause 15:

"{Insert the final normative paragraph of 6.2 at the end of the
description of the FPTR argument to C_F_POINTER in subclause 15.2.3.3.}"

[36:6-7] Replace "and" with a comma.  At the end of the sentence insert
"and constraint C604b.  Move C604b to be immediately after C435 in
subclause 4.5.2.1".

[36:11+] Insert "{In 13.8.2.16 LOCK_TYPE, insert 'nonpointer' before
'variable' in C1303 and C1304.}"

[36:12+] Insert "{In 16.4 Statement and construct entities, in paragraph
1, after 'DO CONCURRENT' replace 'or' with a comma; after 'ASSOCIATE
construct' insert ', or as a coarray specified by a <codimension-decl>
in a CHANGE TEAM construct,'}".

[36:14-15] The characteristics of associating entities of the CHANGE
TEAM construct are described in 5.3.  Replace "and bounds... coselector"
with ", bounds, and cobounds specified in [whatever new subclause number
of 14-007 subclause 5.3 of the TS becomes]."

[36:18+] Insert "{After item (13) in 16.6.7, insert a list item}
  '(13a) a <coarray> in a <codimension-decl> in a CHANGE TEAM construct
         if the coarray named by the corresponding <coselector-name> of
         that construct [", or a subobject thereof," if 14-136 passes]
         appears in a variable definition context within that
         construct;'"

[36:23+] Insert "{In the list item concerning COMMAND_ARGUMENT_COUNT
etc., insert 'in the initial team' after 'image 1'}".

[36:23+] Insert "{In the second list item concerning subclause 13.7,
replace 'CMDSTAT or STATUS' with 'CMDSTAT, STAT, or STATUS'.}" 
Alternatively, change the STAT argument to collective subroutines,
EVENT_QUERY, and MOVE_ALLOC, to STATUS, and change nothing at
[14-007:468:42].  See also the edits suggested for [36:31+] below, which
ought not to be done if the alternative is adopted.

[36:25] Include an instruction to insert subclause numbers in the
newly-inserted list items.

[36:30] Replace with "the relative order of execution of EVENT POST
statements in unordered segments;" for consistency with [15:33-34]. 
[But isn't the relative order of everything in unordered segments
processor dependent?]

[36:31+] If the STAT argument of collective subroutines, EVENT_QUERY,
and MOVE_ALLOC is not changed to STATUS, add three more processor
dependencies:

" o the value of the STAT argument to collective subroutines if an error
    occurs (13.???);
  o the value of the STAT argument to the EVENT_QUERY subroutine if an
    error occurs (13.???);
  o the value of the STAT argument to the MOVE_ALLOC subroutine if an
    error occurs (13.???);"

[40:3] Insert "in the initial team" after "image 1".

[47:11] Delete "in".