(j3.2006) (SC22WG5.5053) [ukfortran] WG5 vote on draft TS on further coarray features

[N.M. Maclaren]

Here is a draft response.  I am sorry about that, but am doing so because
some of my comments may be useful to other people.  I hope to improve it
and include actual changes, but may not get time.



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

    3) No, for the following reasons.



I have included a few points from other people's comments on N1967, but
much of this is from my comments on that.  I have not repeated the
commentary, but most of it remains relevant, and N1971 should be
referred to for that.


Teams
-----

5.1, p9:14-15.  This states "Within the body of a CHANGE TEAM construct
the current team is the subteam specified by the CHANGE TEAM
statement.", which implies lexical scope only.  This should say "Within
the body of a CHANGE TEAM construct and in procedures called from it the
current team ...."

5.2 and 5.3, p9:16-37.  It is still not clear whether TEAM_TYPE has
value or location semantics.  C502 is not enough, because of the
implicit copying implied by passing assumed-shape arrays to
explicit-shape or assumed-size ones, and R502 says 'variable'.  This
must be clarified and is linked to some of the next points [A].

5.3, p10:22-24.  Executing a common CHANGE TEAM statement the same
number of times is not enough, because the variable could be a dummy
argument associated with a different team on different images.  There
needs to be an explicit restriction (probably in lines 14-16) that all
variables must have been created by the same execution of the same FORM
SUBTEAM statement.  See [A].

5.5 p11:4-16 (especially 4, 11-12 and 14).  This is seriously
inconsistent.  FORM SUBTEAM cannot be an image control statement if
it occurs within a segment, ordered or not (Fortran 2008 8.5.2) and,
if it does, it has explicit synchronisation.  I think that the
sentence on line 4 "It is an image control statement." is erroneous
and should be removed.

5.5 p11:12-13.  I have no idea why the restriction on the subscripts
is needed, and cannot see that it does anything useful.  A single
dummy argument can be associated with different variables on different
images and, if it has value semantics, there is no reason to restrict
it in this way.  Indeed, different images can even pass the same
variable in different elements of the same dummy array on different
images.  See [A].

5.5 p11:14-16.  FORM SUBTEAM does not say what happens if an error
occurs, unlike the collectives.

5.6 p11:17+.  There is nothing said about when resources may be
released, and no mechanism for the user to free them.  This is not
reasonable, and there needs to be some defined way for a programmer to
avoid memory leaks when using FORM SUBTEAM heavily.

7.4.13 p22:16-18.  I can find no guarantee that the subteam id. is
assigned in a defined order, and hope that is not the case.  The example
comments should say "Code for half of the images in the current team"
and "Code for the other half of the images in the current team".


Events
------

6.2 p13:15-18.  To avoid the array copying problem, this also needs
to exclude explicit-shape and assumed-size arrays containing event
variables.

6.3 p13:29 and 6.4 p14:2.  The sentences referring to unsuccessful waits
should be removed, as there are no defined conditions that can cause
them to fail and still given them access to the event variable.

6.4 p14:3-7.  At least two responses to N1967 pointed out that the
definition of sequencing makes no sense, on the grounds that ordering
between images is defined only by image control statements, and the
order of these image control statements depends on the ordering between
images!  This is not a simple matter, and simple wording changes will
not resolve it.  As I commented there, the easiest solution to this is
to change events from general semaphores into binary ones, and define an
error return from EVENT POST if the event is already posted.  If this is
not done, some mathematically consistent definition of the ordering must
be provided.  As this appears to be beyond the state of the art in
computer science, it may be hard to achieve.

7.4.11 p21  It needs to say that EVENT_QUERY may be used in segments
that are unordered with respect to EVENT POST on the same variable.


Collectives
-----------

7.3 p15:24+.  Since we have not agreed whether and how collectives
should be consistent with atomics, a Note along the following lines
should be provided:

    Collective subroutines are ordered only by the usual execution
    sequence (2.3.5) and segment ordering (8.5.2) rules and behave
    as if they were implemented using private coarrays to transfer
    the data.  In particular, using them together with atomic
    subroutines in unordered segments is likely to produce effects
    that appear to be inconsistent.

7.3 p15:32-39.  This should state that all INTENT(INOUT) and INTENT(OUT)
arguments become undefined if an error occurs.

7.3 p15:38.  "If an image had failed" should be changed to "If a
processor detects that an image has failed".

7.4.6 p18:2.  "shall be a coarray" is almost certainly erroneous and
should be removed.  If it is a coarray, then all images can access it
directly.  And the usual requirement is to broadcast a local array,
anyway.

Passim.  All collectives except CO_BROADCAST specify that, if SOURCE is
an array, all images must have the same type parameters and shape, but
there is no such wording for scalars.  This is a problem for character
lengths, but may also be one for polymorphic procedures.  Either all
images need to specify that SOURCE is the same, or it needs to state
what happens if that is not the case; the former would be a lot easier
for implementors and to specify.  Specific issues that must be fixed are
described below [B].

Passim.  The specification is messy and restrictive, and should be
changed.  For example, it is not possible to reduce INTENT(IN) examples.
A far better solution would be either two procedures or a generic
interface, of the following forms (CO_REDUCE is used as an example):

    CO_REDUCE (SOURCE, OPERATOR [, STAT, ERRMSG])
    ! SOURCE would be INTENT(INOUT)

    CO_REDUCE (SOURCE, OPERATOR, RESULT [, RESULT_IMAGE, STAT, ERRMSG])
    ! SOURCE would be INTENT(IN)

7.4.6 p18:2-4.  CO_BROADCAST needs to include the same restrictions on
the consistency of type parameters and shape as for the other
collectives.  See [B].

7.4.6 p18:2-4, 7.4.7 p18:16-20 and 7.4.8 p1-5.  If polymorphic
procedures allow the same dummy argument to be different types on
different images, CO_BROADCAST, CO_MIN and CO_MAX need to forbid mixing
numeric and character.  See [B].

7.4.9 p19:37-39.  The last two sentences should be replaced by "OPERATOR
shall implement a mathematically associative and commutative
operation.", as I remember we agreed.

7.4.9 p19:35-39.  This must specify that OPERATOR must implement the
same mathematical function on all images, but I have no idea how to say
that.  Indeed, I am not completely sure that there is no way of
providing different procedures for OPERATOR, because it involves areas
of Fortran I am not familiar with.

7.4.9 p20:8-11.  This must state that the procedure may be called on any
image an indeterminate number of times.


Atomic Intrinsics
-----------------

7.2 p15:13-15.  This specification will cause massive confusion, and it
was clear from WG5 in Delft that there was no agreement on even the
minimal semantics specified by Fortran.  In particular, several people
were assuming levels of consistency that are not always available in
existing hardware, and would need extra work in the compiler to provide.
At the very least, there needs to be a Note saying clearly and
explicitly that currently their behaviour is deliberately left entirely
processor-dependent, and WG5 intends to provide a proper semantic
specification in due course.

Passim.  These must specify that their argument is a coarray, in
the same way as ATOMIC_DEFINE and ATOMIC_REF.


Regards,
Nick Maclaren.