J3/16-283
To: J3
From: Daniel Chen
Subject: Answers to Questions without edits in 16-262r1
Date: 2016 October 11

Discussion:
This paper is to answer the questions raised in paper 16-262r1

=====================================================================
1.
[185-186 11.1.5] If a CHANGE TEAM construct is executed while a
construct is executing, and that construct has a <selector> that is a
coindexed object, does the CHANGE TEAM construct affect the image index
of the association?  I think not, because it doesn't affect the image
index of an actual argument (or at least I hope it doesn't).  A note
might be helpful to stave off a future interp request.  Something like
"Execution of a CHANGE TEAM statement does not affect associations of
coindexed actual arguments to dummy arguments of procedures that have
not completed execution when the CHANGE TEAM statement is executed, or
associations established by constructs that have not completed execution
when the CHANGE TEAM statement is executed." Or this could be said in
11.1.3.3.  Something like "If the <selector> is a coindexed object, the
image to which it refers is not affected by executing a CHANGE TEAM
statement while the construct is executing," and something like that
somewhere in 15.5.2.3.

Answers:
The question is not valid because a <selector> or a dummy argument
is not a coindexed object.
<selector> cannot be a coindexed object as per
"C1103 (R1105) variable shall not be a coindexed object."


2.
[207 NOTE 11.34] Should variables that are referenced or defined by
calls to atomic subroutines have the VOLATILE attribute? Otherwise, how
does the processor know that some other image does not have its value in
a cache?  It probably isn't enough to specify explicitly that it has the
attribute implicitly because an ordinary reference to it might appear in
a different scoping unit from its use in a reference to an atomic
subroutine.  Of should every reference to an atomic subroutine be
preceded and followed by SYNC MEMORY (which seems like a rather large
hammer)?  If they need to have the VOLATILE attribute, its description
should be changed to encompass more than "means other than Fortran."

Answers:
VOLATILE is defined as
[112:24] "The VOLATILE attribute specifies that an object may be
referenced, defined, or become undefined, by means not specified by the
program."
The suggested change breaks the definition of VOLATILE, which is
not desired.


3.
[210:17 R1169] Why doesn't SYNC TEAM allow an integer to specify the
team, as is allowed in an <image-selector>?

Answer:
SYNC TEAM is allowed to sync an ancestor team that is specified by the
team varialbe. A team number is only unique among teams that are created
by the same FORM TEAM statement. Therefore, team number cannot be used
in SYNC TEAM as it is ambiguous.


4.
[213 11.6.10] What happens if an image that other images consider to
have failed actually hasn't, doesn't realize they believe it's failed,
and locks a lock variable?

Answer:
The definition of failed image is:
[14:41]"image that has not initiated termination but which has ceased
to participate in program execution."
Therefore, it cannot lock a lock variable.


5.
[214-215 11.6.11] Are failed or stopped images error conditions, or
simply information made available using the <stat-variable>?  This
affects whether an image control statement without a STAT= specifier
causes error termination if another image has failed, and the wording of
"if an error other than a stopped image or failed image...."

Answers:
Failed images or stopped images are error conditions but they
will cause error termination only if the STAT= specifier is omitted.