From owner-sc22wg5@open-std.org Fri Feb 5 06:39:14 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 4C878C3BA07; Fri, 5 Feb 2010 06:39:14 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 2793 seconds by postgrey-1.18 at www2.open-std.org; Fri, 05 Feb 2010 06:39:12 CET Received: from mail1.cray.com (mail1.cray.com [136.162.62.100]) by www2.open-std.org (Postfix) with ESMTP id C42C0C3BA06 for ; Fri, 5 Feb 2010 06:39:10 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id o154qXC6026423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2010 22:52:33 -0600 (CST) Received: from cfexcas01.americas.cray.com (cfexcas01-2.us.cray.com [172.30.74.227]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id o154qV9U015811; Thu, 4 Feb 2010 22:52:31 -0600 Received: from cf-vpn-192-168-239-12.us.cray.com (192.168.239.12) by cfexcas01.americas.cray.com (172.30.74.226) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 4 Feb 2010 22:52:31 -0600 Message-ID: <4B6BA410.10907@cray.com> Date: Thu, 4 Feb 2010 22:52:32 -0600 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4154) Question about our design for associate names References: <20100205040451.A151BC3BA06@www2.open-std.org> In-Reply-To: <20100205040451.A151BC3BA06@www2.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Van Snyder wrote: > > It would be useful if I could get the "no overlap" semantics with an > associate construct, something like > > associate ( a => newField ( :, :, & > & 1+lowerLon : lowerLon+grid%noLons, & > & 1+lowerLst : lowerLst+grid%noLsts, & > & :, : ), & > & b => grid%field ) > a = b > end associate > > which of course I can write but it doesn't help anything because we > didn't apply the argument restrictions to associate names. > > Do we want to > > (1) add the restrictions to associate names > (a) by way of an interp against 2003, > (b) in 2008 and announce an incompatible change, or > (c) in 2013 and announce an incompatible change, or > (2) not add the restrictions? > I would certainly vote for (2). It has two major advantages: It does not change the current concept that associate constructs are just a mechanism for creating aliases to simplify expressions, and, more important, it would not suddenly invalidate existing codes. > The second choice will result in a feature request for a "these things > don't overlap" declaration that would have effect in the construct or > scope in which it appears. It therefore couldn't tell the compiler that > you know the values of i..n are such that there's no overlap in > x(i:j:k)=x(l:m:n). > > An alternative is an execution construct that only allows assignment > statements in its body and says "there is no overlap in any of the > contained assignments." Why not use DO CONCURRENT? The way people handled the original problem before was to put an 'ivdep' or 'concurrent' directive in front of the array assignment as a way to tell the compiler there would be no cross-iteration dependencies if the assignment was written out as a loop nest (and hence no temp needed). DO CONCURRENT does just that. Pretty close to the same amount of typing and a lot more clear as to what the programmer intends. Malcolm's suggestion of wrapping the assignment in a procedure also works. If the procedure in an internal procedure, or in the same module, it will very likely get inlined and the overhead avoided. Cheers, Bill > > I think it would be simpler to add the restrictions than to invent a new > declaration or construct (especially since I've already drafted the > interp paper). > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101