From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Tue Nov 20 09:18:55 2012
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 7D0BC356957; Tue, 20 Nov 2012 09:18:55 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
X-Greylist: delayed 751 seconds by postgrey-1.34 at www5.open-std.org; Tue, 20 Nov 2012 09:18:53 CET
Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10])
	by www.open-std.org (Postfix) with ESMTP id E01DF356948
	for <sc22wg5@open-std.org>; Tue, 20 Nov 2012 09:18:53 +0100 (CET)
Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105])
	(authenticated bits=0)
	by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id qAK86DsB068588
	for <sc22wg5@open-std.org>; Tue, 20 Nov 2012 08:06:19 GMT
	(envelope-from malcolm@nag-j.co.jp)
Message-ID: <9847F23ED36E4A529B22F1E48A140143@Maru6>
From: "Malcolm Cohen" <malcolm@nag-j.co.jp>
To: "WG5" <sc22wg5@open-std.org>
References: <20121112085727.883FC356954@www.open-std.org> <20121112121725.440BE356955@www.open-std.org>
In-Reply-To: <20121112121725.440BE356955@www.open-std.org>
Subject: Re: [ukfortran] (SC22WG5.4835) WG5 letter ballot 5 on Fortran 2008 interpretations
Date: Tue, 20 Nov 2012 17:06:14 +0900
Organization: =?UTF-8?B?5pel5pysTkFH?=
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

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.

Van Snyder writes re F08/0080:
>I agree with the conclusions, but 7.2.1.3p13 together with 4.8p3 don't
>quite make the answer to Q1 work.   An additional edit at [85:18] is
>needed: Insert "type and" before "type parameters". I think this is
>also needed for an array constructor of the form [ real :: 3, 1.5 ].

I think I would have to agree with this.  The intrinsic type case is clearly 
intended to work otherwise we would not have worded C4104 the way that we did.

I don't however think that this is a fatal flaw in this interp, though we should 
certainly fix it sometime.

So my vote is

Yes  No   Number     Title

-C-  ---  F08/0040   MOVE_ALLOC for coarrays
-Y-  ---  F08/0074   Implicit type in BLOCK construct
-Y-  ---  F08/0077   Function references as variables in DATA statements
-Y-  ---  F08/0078   Are the IEEE values +0 and -0 distinguished
-Y-  ---  F08/0079   NAMELIST and type specification
-C-  ---  F08/0080   Array constructors with polymorphic values
-Y-  ---  F08/0081   Deallocation error handling
-Y-  ---  F08/0082   Generic identifier and dtv arguments

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.