From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Dec 10 12:59:13 2012 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 9F4D43569E9; Mon, 10 Dec 2012 12:59:13 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.tiscali.co.uk [212.74.100.53]) by www.open-std.org (Postfix) with ESMTP id F36B1356981 for ; Mon, 10 Dec 2012 12:59:00 +0100 (CET) X-Trace: 830135140/mk-filter-2.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/TalkTalk_Customer/2.97.126.55/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.97.126.55 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAK2xxVACYX43/2dsb2JhbAANN4wWrxiDWYMSAQEEUyURCyEWDwkDAgECAUUGDQgCqyuJaYkIkQIDjwKDUYMzhViNYw X-IronPort-AV: E=Sophos;i="4.84,251,1355097600"; d="txt'?scan'208";a="830135140" Received: from host-2-97-126-55.as13285.net (HELO [127.0.0.1]) ([2.97.126.55]) by smtp.tiscali.co.uk with ESMTP; 10 Dec 2012 10:00:21 +0000 Message-ID: <50C5B385.9070009@stfc.ac.uk> Date: Mon, 10 Dec 2012 10:03:49 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: WG5 Subject: Re: WG5 letter ballot 5 on Fortran 2008 interpretations References: <20121112085727.883FC356954@www.open-std.org> <50C4AAA6.3060208@stfc.ac.uk> In-Reply-To: <50C4AAA6.3060208@stfc.ac.uk> Content-Type: multipart/mixed; boundary="------------020406070007040809050709" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------020406070007040809050709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the provisional result of the latest ballot on interps. Please let me know by Thurs 9 a.m. (UK time) if you see any errors. Cheers, John. --------------020406070007040809050709 Content-Type: text/plain; charset=windows-1252; name="N1952-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1952-1.txt" ISO/IEC JTC1/SC22/WG5 N1952-1 Result of the interpretations ballot 5, N1949 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N vote fails. Returned to J3 for further work. ? result will be decided by the Convener and /INTERP. The comments are given in alphabetic order, which sometimes causes forward references to later comments. F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0040 0074 0077 0078 0079 0080 0081 0082 Chen Y Y Y Y Y Y Y Y Cohen C Y Y Y Y C Y Y Corbett Y Y Y N C Y N Y Long C Y C Y Y Y Y Y Maclaren C Y Y Y - - Y Y Muxworthy Y Y Y Y Y - Y Y Nagle Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Snyder C Y Y Y Y N C Y Whitlock Y Y Y Y Y Y Y Y Result C Y C ? C ? ? Y Comments and reasons for NO votes F08/0040 Long comment: Minor wording quibble with the last edit : "When a reference to MOVE_ALLOC is executed for which the FROM argument is a coarray...". We typically use "reference" for functions, but not subroutines. An earlier edit in the same interp uses "invoke" which seems to be the more common wording with subroutines. Perhaps the sentence would be better as "When MOVE_ALLOC is invoked with the FROM argument a coarray...". Or "When a CALL to MOVE_ALLOC is executed with the FROM argument a coarray...". Maclaren comment: I am not convinced about the last sentence of the proposed addition to [372:29+] 13.7.118, p6+, because my understanding is that it is not actually required to be a barrier-type synchronisation. Would "may be" be better than "is"? Cohen comment (in reply to Maclaren comment): Short answer: No. Longer answer: I think this needs to be the same kind of synchronisation as ALLOCATE, see 6.7.1.2p4 which contains essentially identical wording (but for ALLOCATE rather than MOVE_ALLOC). Therefore I think this should pass as is. Snyder comment: Edit instructions for [372:18] have a semicolon that ought to be a colon. .................................................................... F08/0077 Long comment: The edit changes constraint C566 to start "A that is a shall be a , not an ." In the text of a constraint, do we really need to say the variable is "not an "? Isn't "shall be a " sufficient? I would prefer to remove ", not an " from the edit. .................................................................... F08/0078 Corbett reason for NO vote: The distinction between +0 and -0 is a fundamental component of the model of floating-point arithmetic defined by IEC 60559. Therefore, I believe the proposed interpretation is flawed. Nonetheless, I would change my vote to yes if a few edits were made. The first line of Note 4.8 [54:18+] is "On a processor that can distinguish between 0.0 and -0.0". I would have that replaced with "On a processor that distinguishes between 0.0 and-0.0". The description of the SIGN intrinsic in clause 13.7.153 includes the phrase "if the processor cannot distinguish between positive and negative real zero". I would have that phrase replaced with "if the processor does not distinguish between positive and negative real zero". Any processor that implements IEEE_COPY_SIGN "can" distinguish between +0.0 and -0.0. .................................................................... F08/0079 Corbett comment: The phrase "kind parameters of the declared type" in the proposed edit appears to be unnecessary. I see no way to specify the declared type of a namelist group object without also specifying the values of the kind type parameters of the declared type. I hope the requirements for "prior specification" will be revisited in the next revision of the standard. .................................................................... F08/0080 Snyder reason for NO vote: I agree with the conclusions, but 7.2.1.3p13 together with 4.8p3 don't quite make the answer to Q1 work. An additional edit at [85:18] is needed: Insert "type and" before "type parameters". I think this is also needed for an array constructor of the form [ real :: 3, 1.5 ]. If there's something else that I've missed that makes this work, my answer to this question is "yes without comment." Cohen comment (in reply to Snyder reason for NO vote): I think I would have to agree with this. The intrinsic type case is clearly intended to work otherwise we would not have worded C4104 the way that we did. I don't however think that this is a fatal flaw in this interp, though we should certainly fix it sometime. .................................................................... F08/0081 Corbett reason for NO vote: I think making it processor dependent whether or not finalizers are executed when a DEALLOCATE statement signals an error condition will create conditions that will lead to corrupted data structures. The only safe action for a program that detects an error condition during execution of a DEALLOCATE statement where a finalizer might be invoked will be to terminate execution. Snyder comment: Either the edit instructions for 459:33+ should say "before" or the position should be 459:36+ --------------020406070007040809050709--