type spec in a forall-header

[Espen_M_]

According to the documentation on IVF 13.1 the forall-header in the DO CONCURRENT construct has the following format:

( [ type :: ] forall-spec [, mask-expr] )

I struggle to get the type spec to compile, e.g.

[fortran]

DO CONCURRENT (integer(int_def) :: i = 1:dim)

[/fortran]

where  int_def is a valid integer kind (used everywhere else in the program so that is not the source of the problem)

The error msg is as follows:

error #5082: Syntax error, found '::' when expecting one of: )

[Steven_L_Intel1]

Yep - looks as if we missed this during implementation. In F2008, a forall-header was expanded to include a type-spec, and our documentation writers picked that up, but the developers overlooked it.  We don't support that in FORALL either. I have passed this on to the developers, issue ID is DPD200250738. Thanks for letting us know.

[TimP]

The option to include the type spec in forall was introduced in f2008 along with the similar option in do concurrent but is not widely used.  It does seem a minor problem with truth in advertising to brag about implementation of do concurrent (even misspelled in some of the ads!) while lacking this feature.

I don't know whether this one is useful enough to be prioritized over other f2008 features, but it certainly will need to be implemented over time.  I suppose it may become more useful as more opportunities are presented for parallelization of forall and do concurrent.

If we can make a fuller story about the advantages of this I'll submit a feature request to test my new post-retirement support account.

[Steven_L_Intel1]

I'm struggling to understand what the point of the type-spec is here - the standard doesn't say much.

We have ads that mention DO CONCURRENT? Doesn't astonish me that there are misspellings.

[Espen_M_]

For me convenience and readability are two arguments. To explain: I wouldn't have to scroll all the way to the specification part if I need a new loop control/index, I can add it there when I need it; I can choose to use more explanatory names instead of the generic i,j,k,... since I find it ugly (in lack of a better word) declaring many such specific loop control variables in the specification part (for now I have to stick with i,j,k, etc.).

Perhaps a stronger argument involves nested DO CONCURRENT constructs: I interpret a loop index declared in the forall-header within another DO CONCURRENT loop as local to that iteration, as opposed to a loop index that is declared outside of the outer loop. Eg:

[fortran]

DO CONCURRENT (INTEGER :: i = 1:m)    !i can lust as well be declared in the surrounding scope
    DO CONCURRENT (INTEGER :: j = 1:n)  !what about j?

         !some code
    END DO

END DO

[/fortran]

If j was declared outside of the outer loop, would this be valid code?

PS: In my opinion all loop counters should be local to the construct

[Steven_L_Intel1]

The index-name (it's not a loop) in a forall-header is a "construct entity". It is an entirely new variable whose scope is the construct (DO CONCURRENT or FORALL.)  The standard sez: "If type-spec appears in forall-header it has the specified type and type parameters; otherwise it has the type and type parameters that it would have if it were the name of a variable in the innermost executable construct or scoping unit that includes the FORALL or DO CONCURRENT, and this type shall be integer type. It has no other attributes." (16.4, paragraph 4)

This brings the declaration local to the place where the variable comes into existence, which is goodness. In your example, if i and j were declared as (or implicitly) integer outside the constructs, they would have the same type and kind in the construct (assuming the type-spec was absent.) With type-spec, it doesn't matter how they are declared elsewhere. The code you show would be valid whether or not j was declared outside the construct.

Other examples of construct entities are in ASSOCIATE, SELECT CASE and BLOCK. There are also "statement entities", such as the index name in an implied-DO in DATA, I/O or array constructors.

[TimP]

Thanks for the preceding discussion.  I see that the IBM Fortran web site has some discussion of "construct entity."

The "construct entity" looks attractive if it could replace the use of OpenMP private variables.  It would give up on the (questionable) concept of firstprivate or lastprivate induction variables.  For now, I think there are too many unanswered questions about forall and do concurrent in parallel applications.

Without the type-spec option, I could make the academic objection that it seems awkward to tie the data type of a new local independent variable to the previous declaration of an entirely distinct variable of the same name, which is shadowed (C terminology, I think) by this new one.  I can imagine worse possibilities when source code which doesn't have implicit none is modified with a possible separate use of the same name.

[Steven_L_Intel1]

Fortran has decades of precedent for statement entities adopting the type from the enclosing scope. But increasingly you don't need to depend on that.

[IanH]

I asked Santa to allow me to have a type spec in an xxx-implied-do loop.  He said I'd been too naughty this year, and was going to give me a push bike instead.  Oh well.  Maybe next standard revision, I mean, year.

[Steven_L_Intel1]

It won't be the next revision, for sure. How do you feel about Fortran 2020?

[IanH]

Well, that was the one I had in mind.  When Santa tried to blame his refusal on my naughtiness I knew he was just making excuses for the difficulty that his factories were having trying to catch up on previous work, plus get his ... teams ... of elves behaving in parallel.

But by then my wish list is going to be a long one...

(Strike through is available as an button in the little text editor widget for these posts, and it changes the text in the widget, but not in the actual visible reply in the forum.)

[Espen_M_]

For some reason I temporarily forgot that the index-name actually is local to the construct when writing my last post; perhaps because the argumet looked much better that my two previous ones. At least I find it much more clean to declare the index-name in the construct statement, the pre-F08 scheme seems half-hearted in some way (and very confusing at first).

Steve Lionel (Intel) wrote:

Fortran has decades of precedent for statement entities adopting the type from the enclosing scope. But increasingly you don't need to depend on that.

Interesting, I thought FORALL was the first one... Care to give a small history lesson to a post-F77 programmer?

[Steven_L_Intel1]

Implied DO in DATA, implied DO in I/O, implied DO in array constructors and, going way back, everything in statement functions. All of these are statement scope and all inherit type from the surrounding scope. FORALL was the first construct scope in the language that did this, however.

[Steven_L_Intel1]

Correction - the loop variables in implied-DO in I/O are NOT statement scope.

[Steven_L_Intel1]

Ian, I've written up a proposal for Fortran 2015 to add type-spec to array constructors and data-implied-do. The next J3 meeting is in February, we'll see what the reception is.

[IanH]

Thanks!

[andrew_4619]

Steve, Just needs a white Beard and a Red Cloak  now Ian? :-)

[Steven_L_Intel1]

The reception to the proposal to add a type-spec to an array constructor was positive - everyone liked it. But...  There was a procedural issue as to how to get this in for F2015. The concern was that if it was just added as a correction of a defect, then that could "open the floodgates" to many other "corrections" that add features. So the agreement was that J3 would ask WG5 (the international committee, which determines what features will be in the standard) to add this as a "work item" for Fortran 2015. This will be done at the meeting in June. I don't anticipate any objection, but if done this way it will discourage a lot of other 1+ requests.

My proposal also included the other construct-association variable in DATA. While there was general distaste for making any enhancements to DATA, which I share, it seemed even odder to me to leave it out. The current version of the proposal is http://j3-fortran.org/doc/meeting/203/14-101r1.txt

As for a white beard, I'm getting there... Still missing the red cloak (but I did receive a black belt in the mail recently...)

[IanH]

Thanks!

Why the apparent antagonism against WHERE?

[Steven_L_Intel1]

http://j3-fortran.org/doc/year/14/14-128r1.txt is the proposal to deprecate WHERE. There was some discussion of separating the WHERE construct (which like FORALL is often misunderstood) from the WHERE statement (which can make sense.) I think the idea is that WHERE and FORALL go together and neither has quite the semantics people expect. (FORALL is already on the list for deprecation.) The suggestion is that DO CONCURRENT can do what WHERE does in a parallel fashion. I recognize that not everyone considers WHERE for its alleged parallel nature.

[FortranFan]

Steve,

I think WHERE and FORALL, when used correctly, make the code easier to read and can state the intent more clearly and concisely than other means, even when parallelism is not of interest.  So I use them often for that purpose.  I don't wish for them to be deprecated.  Is this a done deal, or still under consideration?  Can an ordinary Fortran user like me relay his/her preference to the decision makers in any influential manner?

Thanks,