From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Sep 5 04:49:21 2013 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 E3C6335725B; Thu, 5 Sep 2013 04:49:20 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by www.open-std.org (Postfix) with ESMTP id A622D357087 for ; Thu, 5 Sep 2013 04:49:00 +0200 (CEST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r852mval013290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Sep 2013 02:48:59 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r852muck010553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Sep 2013 02:48:57 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r852muIw028314 for ; Thu, 5 Sep 2013 02:48:56 GMT Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Sep 2013 19:48:56 -0700 Message-ID: <5227F0F2.3020004@oracle.com> Date: Wed, 04 Sep 2013 19:48:18 -0700 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:6.0) Gecko/20110814 Thunderbird/6.0 MIME-Version: 1.0 To: WG5 Subject: WG5 ballot N1988 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Sender: owner-sc22wg5@open-std.org Precedence: bulk The following Fortran 2008 interpretations are being balloted: Yes No Number Title --- -N- F03/0030 IEEE divide by zero -Y- --- F03/0047 Polymorphic arguments to intrinsic procedures -Y- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -Y- --- F03/0064 Recursive declaration of procedure interfaces -Y- --- F03/0100 Error in field width for special cases of signed INFINITY output -Y- --- F03/0139 Functions returning procedure pointers -Y- --- F08/0071 Vector subscript target --- -N- F08/0075 Pointer function reference as variable in assignment --- --- F08/0076 Pointer function reference in READ Subsumed by F07/0075 -Y- --- F08/0083 Type parameter default expressions allow circular dependence -Y- --- F08/0084 Pointer arguments to PURE functions -Y- --- F08/0085 Problems with PARAMETERs -Y- --- F08/0086 Implied-shape and separate PARAMETER statement -Y- --- F08/0087 Mixed-kind character assignment -Y- --- F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? --- -N- F08/0089 Variable-denoting functions change existing semantics -Y- --- F08/0090 What restrictions apply to initialization and PARAMETER? ------------------------- F03/0030 N The Fortran 2008 standard places no requirements on division in its description of IEEE_SUPPORT_DATATYPE (14.9p1, 14.11.24). The proposed edits require a processor to signal IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO as specified by IEC 60559:1989, even though the processor is not required to produce the results specified by IEC 60559:1989 for normal operands returning normal operands unless IEEE_SUPPORT_DIVIDE is true. That makes no sense. For example, consider the case of an Intel 386 CPU with a 387 numeric coprocessor. A Fortran processor for such a system might implement the statement X = X/Y where X and Y are represented in the double-precision format of IEC 60559:1989 by extending the values of X and Y to extended precision performing the division and converting the result back to double-precision. The resulting division would not always produce the result required by IEC 60559:1989. It would also not signal exceptions as required by IEC 60559:1989. The text of the Fortran 2008 standard permits the processor to return true for IEEE_SUPPORT_DATATYPE(X) if it supports the requirements of 14.9, paragraph 1. Given the additional requirement added by the edits, the processor would not be permitted to return true for IEEE_SUPPORT_DATATYPE(X). ------------------------- F08/0075 N The proposed fix adds unnecessary inconsistencies to the language. The treatment of a pointer value that is the result of a function invocation should not depend on the syntactic form of the invocation. It would be better to deal with the syntactic ambiguities by adding constraints restricting the syntax of the variables on the left-hand side of an assignment and in input lists, and leave the semantics unchanged. In particular, the meaning of a selector should not depend on whether for form of the selector is a function reference or an operation. I objected to previous attempts to fix the ambiguities through syntax changes because the proposed changes were too difficult for users to understand. Prohibiting operations from being used as the variable on the left-hand side of an assignment or as a variable in an input list seems like the right fix for the ambiguities. There is no need to apply the restriction to cases such as selectors and specifiers. In general, if a data pointer value appears in a context that permits a data pointer value, it should be treated as a data pointer value. If a data pointer value appears in a context that permits a variable, but not a data pointer value, the pointer value should be treated as the target of the pointer. If a data pointer value appears in a context that requires a nonpointer value, the pointer value should be treated as the value of the target of the pointer. The Fortran 2008 standard hits the mark. The proposed interpretation moves the standard away from the aforestated principles. ------------------------- F08/0089 N Questions Q1 and Q2 assume that if a pointer actual argument has the form of an expression and the corresponding dummy argument is a nonpointer dummy argument without the VALUE attribute, the dummy argument becomes argument associated with the value of the target of the value of the pointer actual argument. On the newsgroup comp.lang.fortran, Ian Harvey pointed out that the Fortran standards do not support that premise. Paragraph 2 of Clause 12.5.2.3 of the Fortran 2008 standard states If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument that is pointer associated with a target, the dummy argument becomes argument associated with that target. Paragraph 8 of Clause 12.4.1.2 of the Fortran 2003 standard states Except in references to intrinsic inquiry functions, if the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be associated with a target and the dummy argument becomes argument associated with that target. Paragraph 6 of Clause 12.4.1.1 of the Fortran 95 standard states If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target The paragraph added between paragraphs 3 and 4 of Clause 12.4.1.1 of the Fortran 90 standard by Corrigendum 2 states If the dummy argument is not a pointer and the corresponding actual argument is, the actual argument must be currently associated with a target and the dummy argument becomes argument associated with that target. That text was added as a result of interpretation F90/000039. In the examples given in questions Q1 and Q2, the actual argument fx() is a pointer actual argument corresponding to a nonpointer dummy argument. Therefore, the dummy argument becomes argument associated with the target of the pointer actual argument, which is the module variable x. The dummy argument does not become argument associated with the value of the target of the pointer. Thus, there is no semantic difference between Fortran 2008 and the previous standards in this regard. The answers and edits given for questions Q1 and Q2 are based on the same premise as the questions themselves and should be rejected. I asked people to compile and run the example programs given in questions Q1 and Q2 and variations of them using a variety of compilers. In most, but not all, cases, the results were consistent with the semantics stated in the Fortran standards, not with the semantics assumed by questions Q1 and Q2. Questions Q3 and Q4 are consistent with the standards, as are the corresponding answers and edits, but I do not care for the nature of the changes that will result if interpretation F08/0075 is passed. I think changing the language so that the form of a function reference determines its meaning is a mistake.