(j3.2006) CD ballot process

[Bill Long]

On Apr 12, 2017, at 3:22 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> I am very disappointed by this process.
> 
> In twenty years (plus one meeting in 1986), I have never seen any other
> paper disappear without any discussion.  Every other paper of mine that
> came out of subgroup with "no action" was discussed with me, either
> in /data or in a sidebar with at least one member of another subgroup.
> No other paper has ever been ruled out of order without discussion.

Well, that?s an issue to take up with the relevant subgroup heads.  However, the topic of locality specs was discussed at length when the feature was up for consideration in F2015.  The consensus was that the benefits substantially out-weighed the negatives.  This is not a feature that appeared out of thin air.  Compiler developers (that I know at least) saw the original locality rules for DO CONCURRENT as difficult to implement, and almost impossible to implement in efficient code.  The new locality specs are very popular with the compiler developers - they offer the user a chance to provide useful information leading to good, efficient code generation. 

> 
> Does anybody care to offer up a reason for keeping locality specs?  I
> gave two reasons why I believe they're undesirable.  Nobody has defended
> them.  Nobody has objected to my reasoning.

One reason appeared to be that the user could just insert OpenMP directives instead.  There are numerous reasons that is a undesirable. These directives apply to OpenMP parallel regions, not Fortran constructs.  And their use would involved dragging the whole OpenMP infrastructure into the program. But most important, for me at least, is that we would be making the Fortran standard dependent on the definitions established for directives by the OpenMP committee.  Not only is this a potentially bad position to be in, but especially so with a committee that is habitually behind in accommodating current Fortran standards. 

The other is to ask users to insert BLOCK constructs inside DO CONCURRENT constructs.  Seems like a kludge to me - asking for cooperation between two constructs instead of providing a clear spec for the single outer one.   And it is less clear how one would distinguish between LOCAL and LOCAL_INIT using this scheme. 

> 
> Here's one more reason, not in 17-144:  They amplify the goofiness of
> statement function dummy arguments, which we decided we sufficiently
> dislike to print them in obsolescent font.  There are too many things
> that get their attributes by magic.  Why add more?
> 
> If we keep the locality specs, could we print them in obsolescent font?

Everyone will get their say on this, but I would say no.   Obsolescent features are ones for which BETTER alternatives exist in the standard. I don?t see how the locality specs meet this requirement.

Cheers,
Bill


> 
> On Wed, 2017-04-12 at 19:01 +0000, Menard, Lorri wrote:
>> Attached is the list as I have it right now.
>> 
>> Please double check that your favorite comment has made it onto the document; chide me gently if it has not.
>> 
>> The only one I *know* might be pulled is the last one
>> 
>> 	Thanks --
>> 
>> 		--Lorri
>> 
>> 
>> -----Original Message-----
>> From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Dan Nagle
>> Sent: Monday, April 10, 2017 12:47 PM
>> To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>> Subject: (j3.2006) CD ballot process
>> 
>> Hi,
>> 
>> Please post to this list an email with
>> 
>> 1. Your vote (approve CD with comment, disapprove CD with comment, abstain, whatever)
>> 
>> 2. Your comments
>> 
>> Lorri will combine the comments into the INCITS .doc form.
>> Please have your comments to Lorri by Wednesday, April 12.
>> Have mercy that Lorri is on East coast time.
>> 
>> Lorri and Debbie work together to make a ballot, including comments.
>> 
>> A two-week ballot will be run with the US vote and comments starting Friday April 14.
>> 
>> The deadlines are a bit tight, but we knew the schedule was aggressive when we approved it.
>> 
>> --
>> 
>> Cheers!
>> Dan Nagle
>> 
>> 
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425