(j3.2006) (SC22WG5.4924) WG5 ballot on first draft TS 18508, Additional Parallel Features in Fortran

Van Snyder Van.Snyder
Fri Mar 8 23:10:08 EST 2013


On Fri, 2013-03-08 at 12:06 +0000, John Reid wrote: 
> WG5,
> 
> In the strategic plan for the coarray TS agreed at Markham (N1925) there 
> appears:
> 
>     Draft TS constructed by J3       2013-02
>     WG5 ballot on draft TS           2013-03
> 
> I am pleased to say that we are on schedule.
> 
> The draft TS is N1967 and the ballot is N1968. Both are attached. There 
> are background notes in N1968 that you should read before reading N1967 
> itself.
> 
> The ballot ends on 8 April.

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

1) Yes.
2) Yes, but I recommend the following changes.
Until I tried to understand 5.4, 5.5, and their relationship to 5.3, I
would have voted "Yes, but..." with edits below.  Instead, I must vote
3) No, for the following reasons.

{The constraint against branching out of a CHANGE TEAM construct (C501
in 13-251/N1967), and parallel constraints on CRITICAL (C811 in 12-007)
and DO CONCURRENT (C824 in 12-007) ought to be gathered into a single
constraint on branching, e.g.,

C845a A branch within a CHANGE TEAM, CRITICAL, or DO CONCURRENT
      construct shall not have a branch target that is outside the
      construct.

but that can be done during integration.}

[13-251/N1968:9:32+ C501+] Insert a constraint

"C501a A RETURN statement shall not appear within a CHANGE TEAM
       construct."

{This, and similar constraints on CRITICAL (C810 in 12-007) and DO
CONCURRENT (C822 in 12-007), ought to be gathered into a single
constraint on the RETURN statement, e.g.

C1269a A <return-stmt> shall not appear within a CHANGE TEAM, CRITICAL,
       or DO CONCURRENT construct.

but that can be done during integration.}

[13-251/N1967:10:21 5.4p1] Replace "greater than zero" by "not be
negative".  But why even that?  Better yet, delete "greater ... is"

[13-251/N1967:10 Note 5.2] After the previous change, replace
"2-MOD(ME,2)" by "MOD(ME,2)".

[13-251/N1967:10 5.4]

{The description of FORM SUBTEAM, and its relationship to CHANGE TEAM,
are inadequate.  Is it necessary for every image of the current team to
execute a FORM SUBTEAM statement, even though it's not an image control
statement?  What happens if only, say, odd-numbered images do it?  And
if so, then what happens when a CHANGE TEAM statement is executed?  The
CHANGE TEAM statement is an image control statement, so one could not
have, e.g.

  IF ( MOD(ME,2) /= 0 ) THEN
    FORM SUBTEAM ( 2-MOD(ME,2), ODD_EVEN )
    CHANGE TEAM ( ODD_EVEN )
    etc.
  END IF

Is prohibition against, e.g.,

  IF ( MOD(ME,2) /= 0 ) FORM SUBTEAM ( 2-MOD(ME,2), ODD_EVEN )
  CHANGE TEAM ( ODD_EVEN )
  etc.

implied by the prohibition to reference an undefined variable?  What if
ODD_EVEN isn't undefined, but inconsistent on even-numbered images with
the result of executing FORM SUBTEAM on odd-numbered images?  E.g.,

  FORM SUBTEAM ( 1+MOD(ME,4), ODD_EVEN )
  IF ( MOD(ME,2) /= 0 ) FORM SUBTEAM ( 2-MOD(ME,2), ODD_EVEN )
  CHANGE TEAM ( ODD_EVEN )
  etc.

I have no suggestions how to repair this problem, because I don't know
the answers to the questions.
}

[13-251/N1967:10 5.5]

{Description of SYNC TEAM is confusing.  What does "images of the team
specified by <team-variable>" mean?  What does "each other image of the
specified team" mean?  Does it mean something like "If image M executes
a SYNC TEAM statement, and the value of SUBTEAM_ID() for image M is S,
then execution of the segment on image M of the segment following the
SYNC TEAM statement is delayed until every image of the current team for
which the value of SUBTEAM_ID() is S executes a SYNC TEAM statement
specifying the same team...."?  Since a team variable cannot be a
coindexed object, is that what "specifying the same team" means?

Suppose one has:

  FORM SUBTEAM ( 1+MOD(ME,4), ODD_EVEN )
  IF ( MOD(ME,2) /= 0 ) SYNC TEAM ( ODD_EVEN )

What happens?  Who waits?

I have no suggestions how to repair this problem, because I don't know
the answers to the questions.
}

[13-251/N1967:15:14 7.2p1] Replace "calls to" by "invocations of".

[13-251/N1967:15:15-16 7.2p1] Delete "A call ... image control
statement."  The effect will reappear in an edit for page 27 below.

[13-251/N1967:27:3+] Insert edit to 12-007:C821 in 8.1.6.6.3 CYCLE
statement

"{Replace C821 in 8.1.6.6.3 CYCLE statement}

"C821 (R831) A <cycle-stmt> within a CHANGE TEAM, CRITICAL, or DO
      CONCURRENT construct shall not belong to an outer construct."

[13-251/N1967:27:3+] Insert edit to replace 12-007:C845 in 8.1.10 EXIT
statement (see also 201-wvs-002).

"{Replace C845 in 8.1.10 EXIT statement}

"C845 An <exit-stmt> within a DO CONCURRENT construct shall not belong
      to that construct or an outer construct; an <exit-stmt> within a
      CHANGE TEAM or CRITICAL construct shall not belong to an outer
      construct."

{This is a slight extension of 12-007, in that it allows an EXIT
statement to belong to a CRITICAL construct but not to an outer
construct.  12-007 prohibits an EXIT statement to belong to a CRITICAL
construct or an outer one.  In e-mail discussion of CHANGE TEAM, it was
argued that it is better to allow an EXIT statement to belong to a
CHANGE TEAM construct than to expect one to put a label on the END TEAM
statement and branch to it, or to enclose the <block> of the CHANGE TEAM
construct in a BLOCK construct and exit the BLOCK construct.  The same
analysis applies to the CRITICAL construct, and for consistency the same
should be allowed for it.
}

[13-251/N1967:27:9+ or thereabouts] Insert a bullet (compare to edits
for F08/0040 concerning MOVE_ALLOC)

"o  a CALL statement that invokes a collective intrinsic subroutine;"

This could be combined with the edit from F08/0040

"o  a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC
    with coarray arguments, or a collective intrinsic subroutine;"

4) Abstain.








More information about the J3 mailing list