From owner-sc22wg5@open-std.org Wed Sep 9 11:52:29 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 BEE69C178E2; Wed, 9 Sep 2009 11:52:29 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1019 seconds by postgrey-1.18 at www2.open-std.org; Wed, 09 Sep 2009 11:52:28 CET DST Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id 3413BC178D9 for ; Wed, 9 Sep 2009 11:52:28 +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]:53768) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1MlJaK-0002nM-PP (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 09 Sep 2009 10:35:28 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1MlJaK-0007zV-Rl (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 09 Sep 2009 10:35:28 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 09 Sep 2009 10:35:28 +0100 Date: 09 Sep 2009 10:35:28 +0100 From: "N.M. Maclaren" To: sc22wg5@open-std.org Subject: Some minor points on the Draft Final CD Message-ID: 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 I have started to look at this and, because I had stepped back from the trees, have noticed a few minor loopholes. I should appreciate comments and corrections before formally passing them on to the UK. 1) I thought that we had discussed this, but now can't find any wording that forbids it, nor what it means if it is allowed: ! running on either 10 (too few) or 27 (not a multiple) images INTEGER, SAVE :: coarray(10)[5,5,*] ! and similarly for ALLOCATE Unless I have missed something, this needs a new paragraph in 5.3.6.3 (Explicit-shape coarray), such as: The product of (upper-cobound - lower-cobound + 1) for all codimensions except the last shall be a factor of the number of images. and in 6.7.1.1 (ALLOCATE statement: Syntax): The product of (upper-cobound-expr - lower-cobound-expr + 1) for all codimensions except the last shall be a factor of the number of images. If not, there needs to be something (even just a NOTE) clarifying what happens in these cases. 2) We seem to have let this one slip through; should we allow it or not? It has essentially the effect of a SYNC ALL, but no image can tell that without synchronising with the others. SYNC_IMAGES( (/ MOD(THIS_IMAGE(),NUM_IMAGES())+1, & MOD(THIS_IMAGE()+NUM_IMAGES()-2,NUM_IMAGES())+1 /) ) I suggest not, on the grounds that it will inconvenience implementors, isn't a particularly sane usage, and could be added later. In 8.5.4 (SYNC IMAGES statement), add a new paragraph: If two SYNC IMAGES statements correspond, the two image sets (extended by adding the executing image if that is not present) shall be the same. 3) I think that the current wording overspecifies error termination in paragraph 4 of 2.3.5 (Execution sequence). Specifically, requiring one image to be able to force with others into termination without them executing any special statement is a heavy burden on implementors, and may not always be feasible. On the other hand, when it isn't possible, the standard can't say anything useful. To put it in other words, is "error termination" intended to mean that the program has failed, or does it really mean "unilateral termination"? If people agree with me, I suggest changing: The synchronization step is executed by all images. to: For normal termination, the synchronization step is executed by all images; for error termination, the synchronization of images is processor dependent. 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