From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Aug 28 20:09:40 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 C9244356925; Tue, 28 Aug 2012 20:09:40 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id 5ACE735690A for ; Tue, 28 Aug 2012 20:09:38 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55572) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1T6QEM-0002jb-QN (Exim 4.72) (return-path ); Tue, 28 Aug 2012 19:09:38 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1T6QEM-0000Ln-5F (Exim 4.72) (return-path ); Tue, 28 Aug 2012 19:09:38 +0100 Received: from [91.125.224.214] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 28 Aug 2012 19:09:38 +0100 Date: 28 Aug 2012 19:09:38 +0100 From: "N.M. Maclaren" To: John Reid Cc: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4728) Ballot 3 on Fortran 2008 interpretations Message-ID: In-Reply-To: <20120818115719.C0FDD35691B@www.open-std.org> References: <20120804040444.460F63568DA@www.open-std.org> <20120806212738.70CE53568F2@www.open-std.org> <20120807182349.20E743568F8@www.open-std.org> <20120818115719.C0FDD35691B@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk My responses to this ballot are appended. Regards, Nick Maclaren. Yes No Number Title -Y- --- F03/0017 Dummy procedure pointers and PRESENT -Y- --- F03/0018 Multiple identical specific procedures in type-bound generic interfaces -Y- --- F03/0019 Multiple identical specific procedures in generic interface blocks -Y- --- F03/0021 What kind of token is a stop code? -Y- --- F03/0046 Unlimited polymorphic pointers in common blocks --- -N- F03/0053 The BIND attribute for C_PTR and C_FUNPTR --- -N- F03/0065 Relational equivalence -C- --- F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine -Y- --- F03/0096 Can a read statement change the unit value? --- --- F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type -Y- --- F03/0116 indistinguishable specifics for a generic interface with use association -Y- --- F03/0118 Are lower bounds of assumed-shape arrays assumed? -Y- --- F03/0120 When are parameterized sequence types the same type? -C- --- F03/0121 Precise FP semantics of the REAL intrinsic -Y- --- F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? -Y- --- F08/0008 IEEE exceptions for intrinsic functions -Y- --- F08/0031 PURE INTENT(OUT) finalization -Y- --- F08/0032 PURE FUNCTION result finalization -Y- --- F08/0038 Are pointless restrictions on DIM arguments intended? -Y- --- F08/0042 SOURCE= questions ----------------------------------------------------------------------- Reason for No on F03/0053: I agree with John Reid that it would be better to state explicitly that they do not have the BIND attribute, but that would not help. Sentences 2 and 3 in 15.3.3 paragraph 2 states that they are interoperable, but sentence 1 of 15.3.4 paragraph states that a derived type is interoperable if and only if the Fortran type has the BIND attribute. A better solution would be to state that, notwithstanding the general rules for derived types, they do have the BIND attribute and are interoperable with C variables of type 'void *' and 'void (*) ()', respectively. This matter should be addressed in a future revision, but it might be easier to do that now than make the current situation consistent. I also agree with John Reid on question (2), and regard the liberty to break the privacy restrictions by using interoperability as a defect in the standard. Reason for No on F03/0065: This is for the same reasons as David Muxworthy. The wording in 7.1.8.5 dates from Fortran 77, but has never truly corresponded with what compilers do, no doubt because of the contradictory wording in 7.1.7.5. Furthermore, if the change to the language is noted, its effects are not limited to simple examples like this one. For example, many processors (including even IEC 60559:1989) have multiple representations of the same value, and it affects which one may be returned. Similarly, the order of evaluations (e.g. in the MAX intrinsic) can become visible; that is particularly problematic, because it (mathematically) depends on solely relational operations. I disagree with the direction of this interpretation and, in any case, think that the question of exactly what a value is needs addressing before an interpretation is appropriate. Reason for Comment on F03/0084 This relates to F03/0065, but is the other way round. Unlike that one, I consider this consistent with the majority of the semantic wording in the C standard. Reason for Comment on F03/0121 The recommendation to use VOLATILE is wrong. There is a common myth in among C and C++ and even in informative text in the standards that volatile implies this semantic, but it is not justified by their normative text, nor do all compilers support it. Fortran should not follow suit - in particular, Fortran 2008 5.3.19 makes no such guarantee. In particular, because 5.3.19 provides licence to the processor and not to the programmer, a compiler is at liberty to optimise all references to VOLATILE variables if it does not provide any method of accessing it other than those specified by the program. Regrettably, the correct response is: There is no feature in Fortran to provide this facility, though assignment to a VOLATILE variable will often work. On some processors, making that a BIND(C) variable in a module will be needed but, on a few, this recipe will not work at all. This should be addressed properly in a future revision.