From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Nov 20 09:46:16 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 8A01D356978; Tue, 20 Nov 2012 09:46:16 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by www.open-std.org (Postfix) with ESMTP id C5526356637 for ; Tue, 20 Nov 2012 09:46:13 +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]:57214) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1TajTA-0007na-sD (Exim 4.72) for sc22wg5@open-std.org (return-path ); Tue, 20 Nov 2012 08:46:12 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1TajTA-00038H-P9 (Exim 4.72) for sc22wg5@open-std.org (return-path ); Tue, 20 Nov 2012 08:46:12 +0000 Received: from [87.113.187.52] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 20 Nov 2012 08:46:12 +0000 Date: 20 Nov 2012 08:46:12 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4839) WG5 letter ballot 5 on Fortran 2008 interpretations Message-ID: In-Reply-To: <20121120081856.6FE92356951@www.open-std.org> References: <20121112085727.883FC356954@www.open-std.org> <20121112121725.440BE356955@www.open-std.org> <20121120081856.6FE92356951@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Nov 20 2012, Malcolm Cohen wrote: >Nick Maclaren writes: >>F08/0040 >> >>I am not convinced about the last sentence of the proposed addition to >>[372:29+] 13.7.118, p6+, because my understanding is that it is not >>actually required to be a barrier-type synchronisation. Would "may be" >>be better than "is"? > >Short answer: No. > > Longer answer: I think this needs to be the same kind of synchronisation > as ALLOCATE, see 6.7.1.2p4 which contains essentially identical wording > (but for ALLOCATE rather than MOVE_ALLOC). > >Therefore I think this should pass as is. Agreed. It's a very ALLOCATE-like use. I could argue that both need improvement, but that's not within the scope of this interpretation. Regards, Nick Maclaren.