(j3.2006) (SC22WG5.5211) [Ballot on draft DTS] -- Added features section

Bill Long longb
Fri Apr 4 17:29:47 EDT 2014

Hi Van,

Your comments included a section "Stuff that might be profitably added?.  For the purposes of the TS, it is too late to be proposing changes like these.  However, I?ll comment on the proposals separately below.

On Apr 3, 2014, at 9:43 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

1) It is processor dependent whether common or independent random number
generators are used, and there's no way to detect which is the
situation.  Therefore taking action using one assumption or the other
(e.g., calling or not calling RANDOM_SEED on each image with a
hopefully-different value, maybe dependent on the image number) might be
the wrong thing to do.  It is preferable to provide a named constant in
ISO_FORTRAN_ENV to indicate whether the processor uses a common random
number generator on all images, or intrinsic procedures so to inquire or
specify.  References to the intrinsic subroutine that specifies whether
common or independent random number generators are used should be image
control statements.  13.5p4 should be adjusted so that the segment
ordering requirement applies only if a common random number generator is

Reply:  While not related to the TS, this is a legitimate issue to raise.  This could be brought up in the context of ?warts? in the current standard. You are not the only one with an interest in random number sequences that are different in each image (and hopefully uncorrelated).  There are trade-offs with this issue, which is partly why it has not been addressed. 

2) Note 5.8 suggests that there ought to be a mechanism to specify, change,
and inquire the image to which standard input is connected.  The OPEN
and INQUIRE statements come immediately to mind.  The image index should
be in the initial team, and connecting should, for consistency, be
allowed in only one image.  Either that, or standard input should be
connected to all images.  A READ statement for a file that is attached
to more than one image should be specified to execute as if in a
critical section.

Reply: This is also mainly an issue with the base standard, although I don?t see the connection to Note 5.8 ?Examples of CODIMENSION??.   One option for the standard input case would be an INQUIRE spec that returned the image number of standard input in the current team, or 0 if the image connected is not in the current team, or something like -1 if it is connected to all images. Or perhaps in intrinsic that returns .true. if the invoking image can read from standard input, and .false. otherwise.   The possibility of having it connected on all images is part of a general question of why we cannot have any file with action of ?READ? open on all images. Nominally, this is sort of allowed now since we are lax on whether a file with the same name on multiple images is really the same file (9.3.1p3). It is fairly straightforward to allow a read-only file to be connected on multiple images as long as each image has an independent view of file position, and hence can read without any need to coordinate with other images. The ?magic? of NFS has existed for decades.  Perhaps we went to far in tossing this simple case in the context of dropping all of multi-image I/O as part of F2008.   But note that this scheme conflicts with the idea of ?execute as if in a critical section?.     Again, a ?wart? candidate, but one in need to more discussion it we go down this path.  (I would note that lack of parallel I/O is one of the more common complaints about coarrays.)

3) A pointer can have a coarray target, but cannot be directly coindexed,
although if they're actual arguments associated with (necessarily
nonpointer, so far) coarray dummy arguments, their target can be
coindexed in the invoked procedure.  Allow coarrays to be pointers. 
Prohibit allocating and deallocating coarray pointers.  In pointer
assignment, require that if the pointer is a coarray, the data target
shall be a coarray.

Reply: An actual argument corresponding to a coarray dummy has to be a coarray (, so I don?t see how the actual can be a pointer.  We did consider the more general case of copointers, and decided against.  You might want to try that concept again for F2015, but it is out of scope for the TS. One of the previous proposals, I believe from IBM, included the limitation that the target had to be a coarray, and was probably very similar to what you have in mind. 


Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

More information about the J3 mailing list