(j3.2006) (SC22WG5.4162) Question about our design for associate names

Van Snyder Van.Snyder
Fri Feb 5 14:50:11 EST 2010

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: to the relationship between associate names and

> > 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 <expr> and <variable> 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. 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).
> > 

More information about the J3 mailing list