From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Sep 11 22:20:50 2014 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 76B04357122; Thu, 11 Sep 2014 22:20:50 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 338 seconds by postgrey-1.34 at www5.open-std.org; Thu, 11 Sep 2014 22:20:49 CEST Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by www.open-std.org (Postfix) with ESMTP id 532923567FE for ; Thu, 11 Sep 2014 22:20:44 +0200 (CEST) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVBIEGzBdG9CQxrbA3/wYGMYadGVtkjYy@postini.com; Thu, 11 Sep 2014 13:20:49 PDT Received: from CFWEX02.americas.cray.com (172.30.74.25) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server (TLS) id 14.2.347.0; Thu, 11 Sep 2014 15:15:06 -0500 Received: from CFWEX01.americas.cray.com ([169.254.1.16]) by cfwex02.americas.cray.com ([169.254.2.144]) with mapi id 14.02.0387.000; Thu, 11 Sep 2014 15:15:05 -0500 From: Bill Long To: WG5 List Subject: Response to ballot in N2028 Thread-Topic: Response to ballot in N2028 Thread-Index: AQHPzf0SbXlsEFAluEyOpHpf38KzjQ== Date: Thu, 11 Sep 2014 20:15:04 +0000 Message-ID: <210909BA-7FEE-4928-B776-DFA2C9CAC1CD@cray.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.219] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7E40C33672986E418D69BD462AA860FF@cray.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Paper N2028 asks: Please answer the following question "Is N2027 ready for forwarding to=20 SC22 as the DTS?" in one of these ways.=20 1) Yes. 2) Yes, but I recommend the following changes.=20 3) No, for the following reasons. 4) Abstain. My vote is 2) Yes, but I recommend the following changes.=20 The following changes are needed. I believe that fixes for all of them are = straightforward.=20 -- 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 =93the argument is assigned the value zero=94 to =93the argument is assigned the value zero if no image in the current team is known to have failed and STAT_FAILED_IMAGE otherwise=94. 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@cray.com Fortran Technical Suport & voice: 651-60= 5-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101