From owner-sc22wg5@open-std.org Wed Oct 21 19:57:02 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 C35AAC178E4; Wed, 21 Oct 2009 19:57:02 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by www2.open-std.org (Postfix) with ESMTP id 3C04FC178E3 for ; Wed, 21 Oct 2009 19:57:01 +0200 (CET DST) 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]:58327) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1N0fQj-00021m-0V (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 21 Oct 2009 18:57:01 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1N0fQj-0003DJ-4c (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 21 Oct 2009 18:57:01 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 21 Oct 2009 18:57:01 +0100 Date: 21 Oct 2009 18:57:01 +0100 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4100) (j3.2006) Standard intrinsics and coarrays Message-ID: In-Reply-To: <20091021171501.21FA4C178E3@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> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk 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. 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. 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. Regards, Nick.