(j3.2006) (SC22WG5.5421) Preliminary result of the WG5 straw ballot on N2040

[John Reid]

WG5,

Here is the preliminary result of the WG5 straw ballot on N2040. Several 
people that usually voted have not done so this time. If any of you do 
so very soon, I will include your vote.

I have not decided what the result should be. There seem to be two 
alternatives:

1. Make a few more changes, checked by the email group, to address the 
comments and send the result to SC22.

2. Ask J3 to make a new version at its Feb. meeting and have a fresh 
informal WG5 ballot on the result.

I favour the first alternative. I think the draft would be good enough 
for a first SC22 ballot. We need to know ASAP if any major changes are 
needed.

Please tell me what you think.

John.
-------------- next part --------------
                                         ISO/IEC JTC1/SC22/WG5 N2045-1

             Result of the WG5 straw ballot on N2040

                         John Reid

N2044 asked this question

Please answer the following question "Is N2040 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.

The numbers of answers in each category were:
3 for 1) Yes (Long, Reid, Whitlock)
2 for 2) Yes, but I recommend the following changes
         (Bader, Nagle)
1 for 3) No, for the following reasons 
        (Maclaren)
0 for 4) Abstain 

Here are the comments and reasons. I have included an edited version 
of the comment of Anton Shterenlikht that appeared in comp-f90 because
he has noticed errors in A.3.1. 

Reinhold Bader

2) Yes, but I recommend the following changes.

[1:7] After "examples" add " that illustrate the semantics described"

Reason: Many of these examples are in the Annex.

[14:30] Replace "constuct" by "construct".

[14:30+] Add the following text: 
"Deallocation of coarrays is delayed until the statement that
 performs the deallocation on all active images of the current
 team has synchronized these images."

Reason: Avoid a race condition for definitions/references to 
 such coarrays on the stalled image (cf. [31:31-34], [36:11-15]). 
 It may be appropriate to also add a note that such a statement 
 must be a DEALLOCATE or a invocation of MOVE_ALLOC, either of
 which must have STAT= specified.

[17:7] Delete superfluous space after "ISO_FORTRAN_ENV".

[33:16+] Add missing bullet
"* extensions of image selector syntax and semantics provide the 
   capability to access coarray data across team boundaries;"

[33:19-20] Replace "provide low-level primitives ... computation;" by
" provide the ability to perform non-trivial operations across image
  boundaries on scalars of some intrinsic types in unordered segments;"

Reason: The text should describe what the atomics do, beyond the 
already existing ones.

[35:24-25] Replace by
"{In 4.5.6.2 The finalization process, replace the text of NOTE 4.48}

An implementation might need to ensure that when more than one coarray 
must be deallocated by execution of a single statement, they are 
deallocated in the same order on all images in the current team."

Reason: The term "event" now has a defined meaning that has nothing to
do with the NOTEs scenario.

[36:35-36] Consider the statement 

SYNC MEMORY

executed by all active images of the current team, one image of which 
has failed. According to the semantics defined here and in [38:25-26] 
error termination must be initiated on each executing image of the 
current team; in particular this involves cross-image activity 
that was not required by Fortran 2008. Was this intended? If not, is 
it sufficient to make the following edit to [36:35]:

Replace "If" by "Except in a SYNC MEMORY statement, if" ?

[37:14] Before "FORM TEAM", insert "\uwave{EVENT POST, EVENT WAIT,}".

Reason: Similar to locks, events only impose one-way segment ordering, 
and this ordering is already defined in [18:21-24], so a SYNC MEMORY
appears unnecessary. See 09-193r2 for the reasoning for LOCK/UNLOCK. 

[37:18+] Add the following text
"{In 8.5.2 Segments, edit the first sentence of NOTE 8.34 as follows}

The model upon which the interpretation of a program is based is that 
there is a permanent memory location for each coarray and that all 
images \uwave{on which it is established} can access it."

[38:13] Delete "on all images"

Reason: For each statement it is clear on which images it is 
executed; this may be a subset of all images.

[42:22] Replace "in the current team when the coarray was established"  
by "in the most remotely removed current or ancestor team in which 
the coarray is established."

Reason: The problem with the present wording is that the set of 
images on which a coarray is established may change throughout 
execution time (and also across images). To avoid ambiguity, I 
suggest looking at the establishment at the point (and the image) 
where the intrinsic is executed. This also seems appropriate 
for assuring composability of the coarray team concept - a huge
UCOBOUND that cannot be addressed by any means in the local 
context would not seem to make sense.

[44:15], [44:17] Replace "subcauses" by "subclauses", twice.
_____________________________________________________________________

Nick Maclaren

3) No, for the reasons given in N2038, N2013 and other votes.  I need to
reiterate that neither response in N2039 even addresses my comments.  I
believe that incorporating the TS into the main standard will cause
serious harm to Fortran, because the (semantic) difficulties cannot be
resolved (let alone specified unambiguously) in the time available.
Indeed, it is not clear even that they ARE soluble, because this TS is
specifying a feature that is beyond the state of the art, and has been
for half a century.  I would be prepared to change my vote to abstain if
the decision to incorporate it were reversed.
___________________________________________________________________

Dan Nagle

Y2) Yes with comment.

Comments

in n2040,
change "functions" to "subroutines" at [31:3]
change "function" to "subroutine" at [31:17]
__________________________________________________

Anton Shterenlikht

A.3.1

In the first example, why x and y are defined as coarray variables? 
This fact seems to be completely unused.

Also, is it not possible for image P to read x_dot_y (line 8) from 
image Q, before this variable has been defined on image Q in line 7?
Is this what Note 7.4 is saying?

In the second example, line 17, j_max is undefined. I think what 
was meant is:

16	integer :: j_max, j_max_location
	j_max = j
17	call co_max(j_max)