ISO/IEC JTC1/SC22/WG5 N1952 Result of the interpretations ballot 5, N1949 In order that this set of interpretations can be incorporated in Corrigendum 2 without waiting for the February meeting, \INTERP and the convener have considered all the comments and decided on responses. Key for the Result line: Y vote passes unconditionally. C vote passes, subject to minor changes noted below. N vote fails. Returned to J3 for further work. 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 C C Y Comments, reasons for NO votes, and decisions of \INTERP. 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. Decision of /INTERP: Pass with the correction of Snyder. Reasons: Comment of Long. Reference applies to subroutines and functions without discrimination; see definition 1.3.120.4, and in 12.5.1 "The forms of procedure references are as follows" ... followed by the syntax for the CALL statement. We use both "reference" and "invoke" for calls of a subroutine, so we do not need to make a change. A search soon yielded this example "In a reference to the intrinsic subroutine MVBITS ..." at the start of 13.2.1p6. Comment of Maclaren. See Cohen comment above. .................................................................... 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. Decision of /INTERP: Pass with this comment applied. .................................................................... 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. Decision of /INTERP: Pass with the two suggested edits applied. .................................................................... 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. Decision of /INTERP: Pass without change. Reasons: The extra change is not necessary at this time. The suggestion should be passed to the editor (or to data subgroup) for consideration in the next revision. The requirements for "prior specification" should be considered in the context of "wart removal". .................................................................... 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. Decision of /INTERP: Pass with the additional edit. .................................................................... 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+ Decision of /INTERP: Pass with Snyder's change. Reason: If the user is getting errors on the DEALLOCATE statement his program is already in trouble. However, he might have arranged for something quite different to be done in this case, which would allow execution to continue safely.