From owner-sc22wg5@open-std.org Tue Nov 11 23:34:47 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 9B533CA3433; Tue, 11 Nov 2008 23:34:47 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by www2.open-std.org (Postfix) with ESMTP id 1BB22C178D9 for ; Tue, 11 Nov 2008 23:34:46 +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]:49697) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:nmm1) id 1L01or-0004kF-Im (Exim 4.70) for sc22wg5@open-std.org (return-path ); Tue, 11 Nov 2008 22:34:45 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L01or-0002PJ-Q8 (Exim 4.67) for sc22wg5@open-std.org (return-path ); Tue, 11 Nov 2008 22:34:45 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 11 Nov 2008 22:34:45 +0000 Date: 11 Nov 2008 22:34:45 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3660) (j3.2006) N1755: Request for new features from MPI Forum Message-ID: In-Reply-To: <20081111214622.271B9C178D6@www2.open-std.org> References: <49137AD3.1070402@lrz.de> <20081111181417.B7A22C178D6@www2.open-std.org> <20081111192352.ED310C178D6@www2.open-std.org> <20081111214622.271B9C178D6@www2.open-std.org> 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 11 2008, Aleksandar Donev wrote: > >> With your proposal, the compiler has to assume that fred may have >> changed. Currently, it does not. > > Wouldn't adding a new attribute ASYNC_EXTERNAL or some such fix this? > This is one of the options mentioned. Possibly. But designing a new semantic concept needs a lot of thought. >> Consider the restrictions on VOLATILE arguments (e.g. no VALUE and no >> INTENT(IN), and the proposal to require it to be set in all scopes or >> none). How many of those would you need to add to ASYNCHRONOUS in order >> to close loopholes opened by your proposal? > >Most of those restrictions apply to *both* VOLATILE and ASYNCHRONOUS (see >Clause 12). If they don't, it is probably an existing bug in the standard! Those don't, and it's not a bug, if you think why the restrictions are there. They don't need to apply to ASYNCHRONOUS, but do to VOLATILE. 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