From owner-sc22wg5@open-std.org Fri Feb 5 17:01:56 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 62992C3BA2A; Fri, 5 Feb 2010 17:01:56 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 890 seconds by postgrey-1.18 at www2.open-std.org; Fri, 05 Feb 2010 17:01:55 CET Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by www2.open-std.org (Postfix) with ESMTP id 4DB74C3BA26 for ; Fri, 5 Feb 2010 17:01:54 +0100 (CET) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o15FajcI031066 for ; Fri, 5 Feb 2010 10:36:45 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o15FkuVu1872080 for ; Fri, 5 Feb 2010 10:46:56 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o15FkuBq004381 for ; Fri, 5 Feb 2010 10:46:56 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o15FktGo004348 for ; Fri, 5 Feb 2010 10:46:55 -0500 In-Reply-To: <20100205053914.890D6C3BA06@www2.open-std.org> References: <20100205040451.A151BC3BA06@www2.open-std.org> <20100205053914.890D6C3BA06@www2.open-std.org> To: longb@cray.com Cc: sc22wg5 MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.4155) Question about our design for associate names X-KeepSent: 99D92E70:BE46733D-852576C1:005564B8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Fri, 5 Feb 2010 10:46:48 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 8.0.1|February 07, 2008) at 02/05/2010 10:46:55, Serialize complete at 02/05/2010 10:46:55 Content-Type: multipart/alternative; boundary="=_alternative 0056AEC6852576C1_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0056AEC6852576C1_= Content-Type: text/plain; charset="US-ASCII" > > 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. Yes, I'll vote for (2) too. From the text in the standard describing the construct, I can not deduce a conclusion that associate-name and selector pair in an ASSOCIATE construct should behavior similarly to actual-arg vs. dummy-arg as if in a function call. > 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. Why not FORALL? I know this suggestion may make me unpopular here. But there is no compiler supports DO CONCURRENT yet, and there is no evidence at this point that DO CONCURRENT construct is anything better than FORALL. I hope I'm wrong here though :-) Cheers, Jim Xia XL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM http://www.ibm.com/software/awdtools/fortran/xlfortran --=_alternative 0056AEC6852576C1_= Content-Type: text/html; charset="US-ASCII"

> > 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.

Yes, I'll vote for (2) too.  From the text in the standard describing the construct, I can not deduce a conclusion that associate-name and selector pair in an ASSOCIATE construct should behavior similarly to actual-arg vs. dummy-arg as if in a function call.



> 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.

Why not FORALL?  I know this suggestion may make me unpopular here.  But there is no compiler supports DO CONCURRENT yet, and there is no evidence at this point that DO CONCURRENT construct is anything better than FORALL.  I hope I'm wrong here though :-)



Cheers,


Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM

http://www.ibm.com/software/awdtools/fortran/xlfortran
--=_alternative 0056AEC6852576C1_=--