From owner-sc22wg5@open-std.org Tue Nov 11 09:17:20 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 9111FC178DC; Tue, 11 Nov 2008 09:17:20 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www2.open-std.org (Postfix) with ESMTP id 4C14DC178D9 for ; Tue, 11 Nov 2008 09:17:17 +0100 (CET) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=[127.0.0.1]) by ns.nag-j.co.jp with esmtp (Exim 4.50) id 1KzoQr-000558-Kr for sc22wg5@open-std.org; Tue, 11 Nov 2008 17:17:05 +0900 Message-ID: <49193FCA.6080302@nag-j.co.jp> Date: Tue, 11 Nov 2008 17:18:18 +0900 From: Malcolm Cohen User-Agent: Thunderbird 3.0a1pre (Windows/2008022014) MIME-Version: 1.0 To: WG5 Subject: [Fwd: Re: (j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 coarray papers] Content-Type: multipart/mixed; boundary="------------050207050402060309010104" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------050207050402060309010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reinhold, I am forwarding this to the WG5 list. One has to be very careful replying to things from the J3 list, as it usually sends it to the J3 list not WG5 and not the original author! Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo. --------------050207050402060309010104 Content-Type: message/rfc822; name="Re: (j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 coarray papers.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: (j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 co"; filename*1="array papers.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-path: Envelope-to: malcolm@nag-j.co.jp Delivery-date: Tue, 11 Nov 2008 17:01:05 +0900 Received: from mail183.messagelabs.com ([62.231.131.67]) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1KzoBM-000506-NS for malcolm@nag-j.co.jp; Tue, 11 Nov 2008 17:01:05 +0900 X-VirusChecked: Checked X-Env-Sender: j3-bounces@j3-fortran.org X-Msg-Ref: server-4.tower-183.messagelabs.com!1226390472!18056780!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [62.231.145.242] Received: (qmail 10126 invoked from network); 11 Nov 2008 08:01:12 -0000 Received: from nagmx1.nag.co.uk (HELO nagmx1.nag.co.uk) (62.231.145.242) by server-4.tower-183.messagelabs.com with SMTP; 11 Nov 2008 08:01:12 -0000 Received: by nagmx1.nag.co.uk (Postfix) id 974C9120160; Tue, 11 Nov 2008 08:01:11 +0000 (GMT) Delivered-To: malcolm@nag.co.uk Received: from mail189.messagelabs.com (mail189.messagelabs.com [85.158.139.179]) by nagmx1.nag.co.uk (Postfix) with ESMTP id 8703A12015F for ; Tue, 11 Nov 2008 08:01:11 +0000 (GMT) X-VirusChecked: Checked X-Env-Sender: j3-bounces@j3-fortran.org X-Msg-Ref: server-8.tower-189.messagelabs.com!1226390471!14201172!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,nag.co.uk X-Originating-IP: [129.174.65.102] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 28623 invoked from network); 11 Nov 2008 08:01:12 -0000 Received: from j3.cos.gmu.edu (HELO j3.cos.gmu.edu) (129.174.65.102) by server-8.tower-189.messagelabs.com with AES256-SHA encrypted SMTP; 11 Nov 2008 08:01:12 -0000 Received: from j3-fortran.org (j3 [127.0.0.1]) by j3.cos.gmu.edu (8.13.1/8.13.1) with ESMTP id mAB7a9m1031846; Tue, 11 Nov 2008 02:36:12 -0500 Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106]) by j3.cos.gmu.edu (8.13.1/8.13.1) with ESMTP id mAB7a77Y031843 for ; Tue, 11 Nov 2008 02:36:08 -0500 Received: from [129.187.15.179] ([129.187.15.179] [129.187.15.179]) by mailout.lrz-muenchen.de with ESMTP; Tue, 11 Nov 2008 08:59:53 +0100 Message-Id: <49193B79.8030807@lrz.de> Date: Tue, 11 Nov 2008 08:59:53 +0100 From: Reinhold Bader User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: fortran standards email list for J3 References: <49137AD3.1070402@lrz.de> <20081110124449.AEBF1C178E0@www2.open-std.org> <20081111030258.C9550C178D9@www2.open-std.org> In-Reply-To: <20081111030258.C9550C178D9@www2.open-std.org> Subject: Re: (j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 coarray papers X-BeenThere: j3@j3-fortran.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fortran standards email list for J3 List-Id: fortran standards email list for J3 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: j3-bounces@j3-fortran.org Errors-To: j3-bounces@j3-fortran.org Hello Malcolm, Malcolm Cohen schrieb: > I have a couple of obvious comments... > [discussion on restriction I want but cannot get] Do you think this is then only a matter of telling users "don't use volatile (array, derived type) coarrays thusly" or something which needs fixing in the standard in a more appropriate manner than suggested by me? > >> Example 2.4 ("Protected Context") is non-conforming since the cited >> restriction is violated by the object in question being VOLATILE within >> the scope of the DO loop. This would apply even if the CASE(1) statements >> were not present. >> > There is no restriction that says a DO index variable cannot have the > VOLATILE attribute, and the "cited restriction" does not even mention > VOLATILE. So I cannot agree with your reasoning. (In fact I think the > example is conforming when used as described in the paper.) I don't agree with that one. Referring to 08-007r2, we have 5.3.19 para1: The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program, or by another image without synchronization. so if the DO index variable is volatile, it will by virtue of its volatility violate the cited restriction, won't it? Or do you consider the program conforming (statistically conforming?) as long as simply by chance the index isn't stomped on by anyone else while DO executes? >> In section 4 ("Behaviour on Commodity Clusters"), the example with the >> INTEGER, VOLATILE :: table(1000)[*] >> has a high likelihood of being non-conforming since again the object is >> not scalar, and there may be updates coming in from other images in an >> unordered segment. > Au contraire, there are no references to the array table in the example > code, only to scalar subobjects thereof. Scalar subobjects of a > VOLATILE object are themselves VOLATILE. And scalar. And thus don't > even fall foul of the imaginary restriction that is not yet in 8.5.1. Nicely put :-) > > Cheers, Best Regards Reinhold _______________________________________________ J3 mailing list J3@j3-fortran.org http://j3-fortran.org/mailman/listinfo/j3 ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. ________________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------050207050402060309010104--