(j3.2006) (SC22WG5.5331) Response to ballot in N2028

[Bill Long]

Paper N2028 asks:

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


My vote is

2) Yes, but I recommend the following changes. 

The following changes are needed. I believe that fixes for all of them are straightforward. 


-- The statement in 7.2p4 that the ATOM argument becomes undefined if
   an error condition occurs is wrong for ATOMIC_REF, where the ATOM
   argument is INTENT(IN) and hence prohibited from becoming
   undefined. For ATOMIC_REF, the VALUE argument is the one that
   becomes undefined. That is currently covered separately at
   [30:9]. The text in 7.2p4 needs to exempt ATOMIC_REF. Optionally
   the case covered at [30:9] text could be moved ot 7.2p4 so that the
   consequences of an error condition are located together.  Edits
   needed at [17:28-29] and possibly [30:9].

-- I find NOTE 7.1 confusing and contradictory. A failed image is one
   for which accesses fail (See 3.4). How can it be indeterminate
   whether a call that involves access to a failed image fails? I
   would prefer to just delete this NOTE.

-- The first para of 7.3 says that collectives are performed over the
   nonfailed images of the current team. That implies that the
   operation can be successful even if there are (ignored) failed
   images in the team. However, the case of STAT returning
   STAT_FAILED_IMAGE is covered in 7.3p5 which describes what happens
   if an error condition occurs. To be consistent with 7.3p1, the
   wording in 7.3p4 needs to be changed to include the failed image
   case there. The last sentence of 7.3p5 needs to be removed, "or
   STAT_FAILED_IMAGE in the intrinsic module ISO_FORTRAN_ENV" removed
   from the previous sentence, and 7.3p4 modified by changing ?the
   argument is assigned the value zero? to ?the argument is assigned
   the value zero if no image in the current team is known to have
   failed and STAT_FAILED_IMAGE otherwise?.  Additionally, since it is
   unusual for a non-zero STAT to indicate success, it would be
   helpful to further explain this situatoin in a NOTE 7.5+.  Edits
   needed at [18:13-14], [18:20-22], and [36:29] (remove "the first").

-- The descriptions of STAT and ERRMSG arguments in 7.3 are
   inconsistent in style. For STAT, we have "... is assigned the value
   zero", whereas for ERRMSG we have "... the processor shall assign
   ..." and "...the processor shall not change...". The STAT form is
   more consistent with other descriptions of the actions of intrinsic
   procedures. Edits needed at [18:26] and [18:27].

-- The EVENT_QUERY suroutine was changed to be an Atomic suborutine in
   this draft. The other Atomic subroutines do not have ERRMSG
   arguments. It would be more consistent to remove the ERRMSG
   argument from EVENT_QUERY. Edits needed at [24:37], [25:6-8],
   [37:1-].


Cheers,
Bill


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