From owner-sc22wg5@open-std.org Wed Jul 7 18:36:08 2010 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 4E922C3BA0E; Wed, 7 Jul 2010 18:36:08 +0200 (CEST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mx1.net.stfc.ac.uk (mx1.net.stfc.ac.uk [130.246.135.223]) by www2.open-std.org (Postfix) with ESMTP id B4855C3BA0A for ; Wed, 7 Jul 2010 18:36:07 +0200 (CEST) X-RAL-MFrom: X-RAL-Connect: Received: from jkr.cse.rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by mx1.net.stfc.ac.uk (8.13.1/8.13.1) with ESMTP id o67GZodC011673; Wed, 7 Jul 2010 17:35:52 +0100 Received: from jkr.cse.rl.ac.uk (localhost.localdomain [127.0.0.1]) by jkr.cse.rl.ac.uk (Postfix) with ESMTP id 417E156255; Wed, 7 Jul 2010 17:35:50 +0100 (BST) Message-ID: <4C34ACE5.1060801@stfc.ac.uk> Date: Wed, 07 Jul 2010 17:35:49 +0100 From: John Reid Reply-To: John.Reid@stfc.ac.uk Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090908 Fedora/1.1.18-1.fc10 SeaMonkey/1.1.18 MIME-Version: 1.0 To: ISO Fortran Subject: Re: (SC22WG5.4282) [ukfortran] certain intrinsics and coindexed objects References: <20100706200940.62F22C3BA05@www2.open-std.org> <20100707105555.45EF3C3BA0A@www2.open-std.org> <4C347F96.30406@lrz.de> In-Reply-To: <4C347F96.30406@lrz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CCLRC-SPAM-report: -2.599 : BAYES_00 X-Scanned-By: MIMEDefang 2.61 on 130.246.135.223 Sender: owner-sc22wg5@open-std.org Precedence: bulk Reinhold, >>> Imagine the program >>> >>> program p >>> integer, allocatable :: x[:] >>> >>> allocate(x) >>> sync all >>> if (this_image() == 2) write(*,*) allocated(x[1]) >>> end program >>> >>> Is this program standard-conforming? >> No, but this program is: >> >> program p >> integer, allocatable :: x[:] >> >> allocate(x[*]) ! You forgot [*] > > This was an out-of-focus typo, sorry. > >> sync all >> if (this_image() == 2) write(*,*) allocated(x) >> ! x[1] is an expression, not an allocatable array > > I was hoping for this, but where in the standard does it say so? 5.3.3 says: "An entity with the ALLOCATABLE attribute is a variable for which space is allocated by an ALLOCATE statement (6.7.1) or by an intrinsic assignment statement (7.2.1.3)." You can't put x[1] in an ALLOCATE statement because R632 allocate-object is variable-name or structure-component and x[1] cannot be allocated by an intrinsic assignment statement because 7.2.1.2 says (3) the variable and expr shall be conformable unless the variable is an allocatable array that has the same rank as expr and is neither a coarray nor a coindexed object, So x[1] is not allocatable, which is what allocated requires. I was wrong to say it is an expression. The relevant thing is that it is not allocatable. > From 6.1 and 6.2 it seems that one could rather conclude the > opposite. There are some situations where this is fine e.g., > > type :: f > integer, allocatable :: i(:) > end type > type(f) :: o_f > > ... allocated(o_f%i) There is no coindexed object here, so it is not relevant. > > and some where it's clear that it doesn't make sense (e.g. > array sections). Note that the ALLOCATE statement has > > R632 allocate-object is variable-name > or structure-component > and any bounds or cobounds are separately specified. > Such an allocate-object is also the only thing that can > appear in DEALLOCATE. Why isn't the same applied > to ALLOCATED? Perhaps we should have, but I think the effect is the same. Cheers, John.