From owner-sc22wg5@open-std.org Wed Oct 21 20:27:11 2009 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id C9C6EC76BB7; Wed, 21 Oct 2009 20:27:11 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by www2.open-std.org (Postfix) with ESMTP id D96ADC178E4 for ; Wed, 21 Oct 2009 20:27:09 +0200 (CET DST) Received: from mprox1.jpl.nasa.gov (mprox1.jpl.nasa.gov [137.78.160.140]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9LIR7gS008990 for ; Wed, 21 Oct 2009 11:27:07 -0700 Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated bits=0) by mprox1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n9LIR5dq025634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Oct 2009 11:27:05 -0700 Subject: Re: (j3.2006) (SC22WG5.4101) [ukfortran] Standard intrinsics and coarrays From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <20091021175702.E4D26C178E3@www2.open-std.org> References: <20091020111544.C0F5CC178E3@www2.open-std.org> <20091020154252.946EAC178E3@www2.open-std.org> <20091021161933.1B2FCC178E3@www2.open-std.org> <20091021171501.21FA4C178E3@www2.open-std.org> <20091021175702.E4D26C178E3@www2.open-std.org> Content-Type: text/plain Organization: Yes Date: Wed, 21 Oct 2009 11:27:03 -0700 Message-Id: <1256149625.13106.705.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Wed, 2009-10-21 at 10:57 -0700, N.M. Maclaren wrote: > On Oct 21 2009, Aleksandar Donev wrote: > > > >Once Nick has a final draft with Bill's suggestions taken into account I > >will take a closer look and comment. > > Here is what I currently have: > > We seem to have forgotten to specify how the intrinsic procedures may > be used as far as their use in unordered images is concerned - or, at > least, I can't find anything. However, I don't think that there is much > of a problem. 13.5 paragraph 2 and Table 13.1 is the starting point, > and a lot of my proposal is already implied for those of classes E, ES > and PS by other wording. Those of class A are already covered. > > I have drafted the hard line on random numbers; it would be possible to > make the 'shall be' conditional on the processor dependence, but that is > messy. > > Proposal: > > In 13.5, Standard generic intrinsic procedures, after Table 13.1, add > the new paragraphs: > > It is processor dependent whether EXECUTE_COMMAND_LINE may be called > on any image other than image 1. I would prefer that the effect of calling EXECUTE_COMMAND_LINE on more than one image is processor dependent. I can imagine writing a file with an image-dependent name, running some external process synchronously with its input piped from that file and its output piped to a file with a different image-dependent name, then opening and reading that file. > If RANDOM_SEED is called in a segment A, and either RANDOM_SEED or > RANDOM_NUMBER is called in segment B, then segments A and B shall be > ordered. It is processor dependent whether all images use a common > generator or whether each image uses a separate one. Segment A and segment B should be explicitly different segments in this discussion. > It is processor dependent whether the results returned from > COMMAND_ARGUMENT_COUNT, CPU_TIME, DATE_AND_TIME, GET_COMMAND, > GET_COMMAND_ARGUMENT, GET_ENVIRONMENT_VARIABLE and SYSTEM_CLOCK are > dependent on which image calls them. > > NOTE 13.x > This means that it is unspecified whether images use synchronized > clocks, whether CPU_TIME returns a per-image or per-program value, > whether all images run in the same time zone, whether the count rate > and maximum in SYSTEM_CLOCK are the same for all images, and whether > all images run in the same command environment. It is likely that > they will behave differently on shared memory systems and some > distributed memory ones. For maximum portability, programs should > inspect the command environment and call DATE_AND_TIME only on > image 1. > > The use of all other standard intrinsic procedures in unordered > segments is subject only to their argument use following the rules > in 8.5.2. Edits will be needed in Annex A.