From owner-sc22wg5@open-std.org Thu Nov 13 15:23:36 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 45C4BCA5FE5; Thu, 13 Nov 2008 15:23:36 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by www2.open-std.org (Postfix) with ESMTP id AF70FCA343B for ; Thu, 13 Nov 2008 15:23:34 +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]:36901) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1L0d6c-0001Bg-K8 (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 13 Nov 2008 14:23:34 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L0d6c-0004IF-7T (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 13 Nov 2008 14:23:34 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 13 Nov 2008 14:23:34 +0000 Date: 13 Nov 2008 14:23:34 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3678) (j3.2006) N1755: Request for new features from MPI Forum Message-ID: In-Reply-To: <20081113134429.8439DC178D9@www2.open-std.org> 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> <20081113091819.F182BCA343B@www2.open-std.org> <20081113134429.8439DC178D9@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="-1870869256-1804289383-1226586214=:32427" Sender: owner-sc22wg5@open-std.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1870869256-1804289383-1226586214=:32427 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 On Nov 13 2008, Aleksandar Donev wrote: > >This argument is not progressing too much, so better to end soon. But: Unfortunately, it needs resolving. Whether that will be possible in Tokyo or not, I don't know. But I agree that this will have to stop :-) >> 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. > >That is not at all what I or the paper I mentioned (08-165) said. If the >variable has pending I/O on it, then the dummy should have asynchronous >as well. I can't find any such proposal in that paper. Because it is a change of specification, adding an extra constraint, it needs to be in normative text. I agree that you say such a constraint is needed - and I agree with you. But there is currently no such constraint. > The processor needs to do nothing different, since it is as if >the variable were not asynchronous, at that point in time. The issue of >"may" versus "is" I am not sure of. I am. I attach a program that shows the problem. Please note that this one was debated to death in the early 1970s (yes, in the context of Fortran 66), and the people who claimed that Fortran mandated call-by-reference were roundly defeated. Fortran 90 introduced constructs that REQUIRE some other mechanism (Iliffe vectors, Jensen's device, call by value/return or whatever). And both are well established in compilers and applications, in a way that ASYNCHRONOUS and VOLATILE aren't. >Without this, you make asynchronous useless, since you cannot even call >an old library routine on that variable, even if there is no async I/O >pending or happening. That would indeed be a BUG in the standard. It is currently almost useless, as my evidence shows. In order to get it right, you have to implement asynchronous I/O synchronously (but can do it in either the data transfer or the WAIT). That is what Intel 10.1 seems to do. >And at this point in the game, we cannot change our minds to require >async/volatile to be matched between dummy and actual. All combinations >are allowed in F2003, and must remain so. ... Even if that is inconsistent with its stated intent and the rest of the standard? Oh, come now! ISO SC22 rules allow for incompatible changes where they fix clear defects, and I assume that ANSI X3 is similar. 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 ---1870869256-1804289383-1226586214=:32427 Content-Type: application/octet-stream; name=Asynchronugh Content-Disposition: attachment; filename=Asynchronugh Content-Description: Asynchronugh Content-Transfer-Encoding: BASE64 TU9EVUxFIEdsb2JhbAogICAgSU5URUdFUiwgU0FWRSwgQVNZTkNIUk9OT1VT IDo6IGFycmF5KDQsNCw0KSA9IDAKRU5EIE1PRFVMRSBHbG9iYWwKClBST0dS QU0gTWFpbgogICAgVVNFIEdsb2JhbAogICAgSU5URUdFUiA6OiBpZAogICAg T1BFTiAoVU5JVD0xMSwgQVNZTkNIUk9OT1VTPSd5ZXMnLCBGSUxFPScvZGV2 L3R0eScpCiAgICBSRUFEIChVTklUPTExLCBGTVQ9KiwgQVNZTkNIUk9OT1VT PSd5ZXMnLCBJRD1pZCkgYXJyYXkKICAgIENBTEwgRnJlZChhcnJheSgzLDI6 MywyKSkKICAgIFdBSVQgKFVOSVQ9MTEsIElEPWlkKQogICAgUFJJTlQgKiwg J01haW4nLCBhcnJheQoKQ09OVEFJTlMKCiAgICBTVUJST1VUSU5FIEZyZWQg KGFyZykKICAgICAgICBJTlRFR0VSLCBBU1lOQ0hST05PVVMgOjogYXJnKDop CiAgICAgICAgSU5URVJGQUNFCiAgICAgICAgICAgIFNVQlJPVVRJTkUgSm9l IChhcmcpCiAgICAgICAgICAgICAgICBJTlRFR0VSIDo6IGFyZyg6KQogICAg ICAgICAgICBFTkQgU1VCUk9VVElORSBKb2UKICAgICAgICBFTkQgSU5URVJG QUNFCiAgICAgICAgQ0FMTCBKb2UoYXJnKQogICAgRU5EIFNVQlJPVVRJTkUg RnJlZAoKRU5EIFBST0dSQU0gTWFpbgoKU1VCUk9VVElORSBKb2UgKGFyZykK ICAgIElOVEVHRVIgOjogYXJnKDopCiAgICBDQUxMIEFsZihhcmcpCkVORCBT VUJST1VUSU5FIEpvZQoKU1VCUk9VVElORSBBbGYgKGFyZykKICAgIElOVEVH RVIgOjogYXJnKCopCiAgICBDQUxMIEJlcnQKRU5EIFNVQlJPVVRJTkUgQWxm CgpTVUJST1VUSU5FIEJlcnQKICAgIFBSSU5UICosICdOb3cgc3RhcnQgdHlw aW5nJwpFTkQgU1VCUk9VVElORSBCZXJ0CgoKCjExMSAgMTEyICAxMTMgIDEx NCAgMTIxICAxMjIKMTIzICAxMjQgIDEzMSAgMTMyICAxMzMgIDEzNAoxNDEg IDE0MiAgMTQzICAxNDQgIDIxMSAgMjEyCjIxMyAgMjE0ICAyMjEgIDIyMiAg MjIzICAyMjQKMjMxICAyMzIgIDIzMyAgMjM0ICAyNDEgIDI0MgoyNDMgIDI0 NCAgMzExICAzMTIgIDMxMyAgMzE0CjMyMSAgMzIyICAzMjMgIDMyNCAgMzMx ICAzMzIKMzMzICAzMzQgIDM0MSAgMzQyICAzNDMgIDM0NAo0MTEgIDQxMiAg NDEzICA0MTQgIDQyMSAgNDIyCjQyMyAgNDI0ICA0MzEgIDQzMiAgNDMzICA0 MzQKNDQxICA0NDIgIDQ0MyAgNDQ0CgoKCkludGVsIDEwLjEgJ3N1cHBvcnRz JyBhc3luY2hyb25vdXMgSS9PIGJ5IGRvaW5nIGl0IHN5bmNocm9ub3VzbHks IHdoaWNoCmlzIGEgdmVyeSByZWFzb25hYmxlIHNvbHV0aW9uIHRvIHRoaXMg Zmlhc2NvLiAgTm8gb3RoZXIgY29tcGlsZXIgSQpjdXJyZW50bHkgaGF2ZSBh Y2Nlc3MgdG8gc3VwcG9ydHMgaXQuCgpZb3UgY2FuIHRlc3Qgd2hhdCBpdCB3 b3VsZCBkbyBieSByZW1vdmluZyB0aGUgSS9PIGluIHRoZSBtYWluIHByb2dy YW0KYW5kIHJlcGxhY2luZyBzdWJyb3V0aW5lIEJlcnQgYnkgdGhlIGZvbGxv d2luZy4gIFllcywgSSBrbm93IHRoYXQgdGhpcwptYWtlcyB0aGUgcHJvZ3Jh bSBub3QgY29uZm9ybWluZy4KClNVQlJPVVRJTkUgQmVydAogICAgVVNFIEds b2JhbAogICAgRE8gaSA9IDEsIDQKICAgICAgICBETyBqID0gMSwgNAogICAg ICAgICAgICBETyBrID0gMSwgNAogICAgICAgICAgICAgICAgYXJyYXkoaSxq LGspID0gaSsxMCpqKzEwMCprCiAgICAgICAgICAgIEVORCBETwogICAgICAg IEVORCBETwogICAgRU5EIERPCkVORCBTVUJST1VUSU5FIEJlcnQKCg== ---1870869256-1804289383-1226586214=:32427--