From owner-sc22wg5@open-std.org Fri Feb 5 20:50:17 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 EE49FC3BA1D; Fri, 5 Feb 2010 20:50:16 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by www2.open-std.org (Postfix) with ESMTP id D6996C3BA07 for ; Fri, 5 Feb 2010 20:50:14 +0100 (CET) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o15JoCSd022236 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Fri, 5 Feb 2010 11:50:13 -0800 Subject: Re: (j3.2006) (SC22WG5.4155) Question about our design for associate names From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <20100205053914.890D6C3BA06@www2.open-std.org> References: <20100205040451.A151BC3BA06@www2.open-std.org> <20100205053914.890D6C3BA06@www2.open-std.org> Content-Type: text/plain Organization: Yes Date: Fri, 05 Feb 2010 11:50:11 -0800 Message-Id: <1265399412.2174.258.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Thu, 2010-02-04 at 20:52 -0800, Bill Long wrote: > > 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. There are very few codes that have associate constructs in them. Of those, a vanishingly small number (my guess today would be zero) would be invalidated by applying the restrictions on arguments from 09-007r3:12.5.2.3 to the relationship between associate names and selectors. > > 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. Did I miss something about DO CONCURRENT? Hmmm, nothing (for example) about ordinary DO constructs within DO CONCURRENT. I thought DO CONCURRENT simply said there's no relationship between loop iterations. I took that to mean from one execution of the loop body to another, not from one execution of every explicit or implied loop within it to another. Maybe we should add some words prohibiting the appearance within a DO CONCURRENT construct of those assignments in which a temp would be required. How about C826a An intrinsic assignment in which both and are pointers, or one is a pointer and the other has the TARGET attribute, shall not appear within a DO CONCURRENT constuct. OOPS, that's exactly the case that's causing the problem. Of course, this doesn't do anything for the x(i:j:k) = x(l:m:n) case when x is not a pointer. The case k==n and mod(l-i,k)==0 and either i <= l <= j or i <= m <= j or l <= i <= j or m <=i <= j or ... can't be in a constraint, and would be hard to explain in ordinary text -- and of course that doesn't cover everything. 12.5.2.3 does exactly the right thing. Maybe that could be pounded into the DO CONCURRENT mold. > 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. I suppose I could put one of these (for each type, kind and rank) in every procedure that has an assignment involving pointers. I'd probably use include to do it. It's a Good Thing that we extended generics to internal procedures. I suppose one of the advantages of doing the assignment in a procedure is that the details of what's done are pushed maybe a thousand lines from where it's needed, so that makes the code infinitely easier to understand. > 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). > > >