From owner-sc22wg5@open-std.org Thu Nov 13 10:18:19 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id BD6A5CA5FE5; Thu, 13 Nov 2008 10:18:19 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id 02957CA343B for ; Thu, 13 Nov 2008 10:18:18 +0100 (CET) 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]:47043) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1L0YLB-000895-PF (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 13 Nov 2008 09:18:17 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L0YLB-0003lC-QC (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 13 Nov 2008 09:18:17 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 13 Nov 2008 09:18:17 +0000 Date: 13 Nov 2008 09:18:17 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: (j3.2006) (SC22WG5.3666) [ukfortran] N1755: Request for new features from MPI Forum Message-ID: In-Reply-To: <491B9DAE.4060906@llnl.gov> References: <49137AD3.1070402@lrz.de> <20081111214622.271B9C178D6@www2.open-std.org> <20081111223447.BD40BC178D9@www2.open-std.org> <20081111224927.8201CC178D9@www2.open-std.org> <20081112085745.2228AC178D9@www2.open-std.org> <491B9DAE.4060906@llnl.gov> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Nov 13 2008, Aleksandar Donev wrote: > >I am confused as to whether this should go to WG5 or J3. I thought we >were not to have long technical arguments on WG5? One might hope that, at this stage of the process, it wouldn't be necessary to have long technical arguments. But, as always, reality strikes .... :-( >> Eh? What about NOTE 12.22? > >Do you get WG5 e-mails? Did you get my response to your message and take >a look at paper 08-165 and also 08-165r1.txt from meeting 184? That >paper of mine changed that Note! I don't have the exact new text (the >paper gives diff edits), but the intention is: >"That is, the aversion to copy-in/out is only necessary, and therefore >should only apply, if there is any chance that the volatility and/or >asynchronicity is active either before or after the procedure call; >there is no problem if it is limited to only being within the called >procedure itself." Malcolm has addressed the WG5 versus J3 issues. I am associated with the BSI not J3 and don't track J3 Emails. I don't have time - Fortran is only one of a dozen areas that I need to keep up with. I get the WG5 Emails, yes, but I don't remember anything that referred to those. As I mentioned, I currently have only a ghastly Email interface. Anyway, I have looked at it now. My conclusion is different from yours. I had misunderstood that dropping the VOLATILE and ASYNCHRONOUS attributes was allowed; several vendors did, too. If that remains, I shall have to add yet more statements to my courses "Do not touch this facility with a bargepole and, if you have a program with it in, seek expert help immediately." In particular, allowing VOLATILE and ASYNCHRONOUS to be dropped should be regarded as an error in the standard, as it FORCES copy-in/copy-out in a way that even passing an assumed-shape array to an assumed-side one does not :-( The reason for that is that, once you have dropped them, none of the constraints on argument passing apply at the next level down. Even C volatile and const get THAT one right (modulo the various loopholes). It is also totally foul to implement for ASYNCHRONOUS :-( Consider a variable Wurzel with the ASYNCHRONOUS attribute that MAY have pending I/O on it, and is passed as an argument to a procedure without ASYNCHRONOUS. As I read the wording, that is permitted even if there IS pending I/O unless that procedure actually references, defines, undefines or changes Wurzel. Obviously, the processor is not allowed to copy it back in that case, so it has to perform a run-time check on whether there is pending I/O on Wurzel - without necessarily having any relevant ID to hand! I regard that as a BUG in the standard. >>> 2. "C559 An entity with the VOLATILE attribute shall be a variable that >>> is not an INTENT (IN) dummy argument." Please explain this one to me. >> Bill has explained this one. > >Except that, in my response, and Van's, we specifically disagreed with >the "explanation" and essentially called it an obfuscation. Did you read >those? You did. I refrained from responding, as my response would to have been similar to yours, but the other way round. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679