(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