From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Sep 21 20:40:48 2011 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 CACB03568D7; Wed, 21 Sep 2011 20:40:48 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 326 seconds by postgrey-1.34 at www5.open-std.org; Wed, 21 Sep 2011 20:40:46 CEST Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by www.open-std.org (Postfix) with ESMTP id 4DF883568CC for ; Wed, 21 Sep 2011 20:40:43 +0200 (CEST) Received: from cfexcas02.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKTnovq3YzZqjB1QnFizzPbitm6UzqCDvC@postini.com; Wed, 21 Sep 2011 11:40:47 PDT Received: from CFWEX01.americas.cray.com (172.30.88.25) by cfexcas02.americas.cray.com (172.30.74.223) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 21 Sep 2011 13:35:17 -0500 Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 21 Sep 2011 13:35:16 -0500 Message-ID: <4E7A2ECD.7060001@cray.com> Date: Wed, 21 Sep 2011 13:37:01 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: sc22wg5 Subject: (SC22WG5.4526) WG5 ballot on interpretations - N1876 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Following are my (Bill Long, Cray Inc.) votes for the interp ballot in N1876: The following Fortran 2003 interpretations are being balloted: Yes No Number Title -Y- --- F03/0030 IEEE divide by zero -Y- --- F03/0048 Control edit descriptors in UDDTIO -Y- --- F03/0085 Finalizing targets of pointer or allocatable -Y- --- F03/0091 Array components cannot depend on length type parameters -C- --- F03/0096 Can a read statement change the unit value? -Y- --- F03/0105 SIZE= specifier and UDDTIO -Y- --- F03/0110 Restoring dropped restriction on ENTRY -C- --- F03/0121 Precise FP semantics of the REAL intrinsic -Y- --- F03/0123 Implicit typing in derived types -Y- --- F03/0124 definition is poorly defined -Y- --- F03/0128 Subobjects in namelist output -Y- --- F08/0001 Generic resolution with pointer dummy arguments -Y- --- F08/0002 Are assumed- or deferred-shape objects allowed in namelist? -Y- --- F08/0003 Is a disassociated pointer allowed as an actual DIM argument? -Y- --- F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? F08/0005* optional arguments and ASSOCIATED - subsumed by F08/0004 -Y- --- F08/0006 generic resolution with banned argument combinations -Y- --- F08/0007 Can zero have more than one bit sequence representation? -Y- --- F08/0008 IEEE exceptions for intrinsic functions -Y- --- F08/0009 Is ABS ever required to be the optional IEC 60559 abs? -Y- --- F08/0010 deallocating objects that are associated with other objects -Y- --- F08/0011 How many times are constructed values finalized? F08/0012* Are constants finalized? - subsumed by F08/0011 -Y- --- F08/0013 How does finalization interact with allocatable assignment? --- -N- F08/0014 Finalizing assignment to vector-subscripted object -Y- --- F08/0015 IMPLICIT -C- --- F08/0016 Can a vector-subscripted argument become undefined? -C- --- F08/0017 Elemental subroutine restrictions -Y- --- F08/0018 Impure elemental restrictions -Y- --- F08/0019 Transformational Bessel functions -Y- --- F08/0020 FINDLOC and logical arguments Comments for C and N votes: F03/0096: The wording of the second edit suggests that the SIZE= value returned cannot depend on the input list, which is not what is intended. I think this can be corrected by adding " the values of" after "shall not depend on" in the edit. F03/0121: My reading of the original question included a a desire to say that the result value for REAL(X, KIND=wp), for a particular value of X, is the SAME result value independent of the context in which the function reference appears. After all, it would not really be a "function" in the normal sense if that were not the case. The subsequent discussion in the ANSWER section could cast doubt on whether this basic requirement is actually true. It would be better to explicitly state that REAL for a particular set of arguments always returns the same result value independent of the context. F08/0014: The proposed edit is to add this text: "A vector-subscripted array section shall not be finalized by a nonelemental final subroutine". This is stated as a requirement on the user (program). It is unclear to me what this really means. Here are some options that come to mind: 1) For a type that specifies final subroutines, if a vector-subscripted array section of that type appears in a context where it would be finalized, the type shall specify an elemental final subroutine. 2) For a type that specifies final subroutines, if a vector-subscripted array section of that type appears in a context where it would otherwise be finalized, the section is not finalized if there is no elemental final subroutine. 3) For a type that specifies final subroutines, a vector-subscripted array section of that type shall not appear in a context where it would be finalized unless the type specifies an elemental final subroutine. F08/0016: In the third line of the ANSWER, there is a typo: "copvers" -> ""covers". F08/0017: The discussion section paragraph: "The subroutine test_add does not do anything useful other than to set the IEEE_OVERFLOW flag when x+y would overflow." This is a bit of a shock, since almost all compilers would, in fact, not perform the addition at all in test_add. Certainly we are not intending to imply that this common optimization is now illegal. Subroutine test_add contains no references to the IEEE modules. I would prefer to either delete this paragraph from the ANSWER, or to delete the end of the sentence following "useful". Further, the calls to the IEEE routines in the caller are a distraction from the point of the question, and could be deleted as well. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101