topic Thanks. In usual style I now in Intel® Fortran Compiler

Meaning of "variable is defined" in the context of coarrays

IanH — Mon, 05 Aug 2013 05:06:00 GMT

Those who follow c.l.f will have seen this question from me a few weeks back (this might link to it).

In F2008 it says for non-atomic operations that "if a variable is defined on an image in a segment, it shall not be referenced, defined or become undefined in a segment on another image unless the segments are ordered."

I'm not sure whether "a variable" means the entire coarray involved in the definition, or just the specific subobjects of a coarray that might be defined. On c.l.f. I got an answer from someone who definitely knows their stuff that it was definitely the whole thing. I got another answer from someone who similarly definitely knows their stuff that it was definitely just the subobjects (through example of what was considered valid). This difference in deduction around the definition of "is defined" definitely deflated me.

What does Intel Fortran think?

If the answer is "just the specific subobjects", how does ifort manage "partial" updates (some subobjects only) to a coarray if it isn't using shared memory?

(I'm wondering whether there's something I'm missing given the apparent careful use of the terms "variable", "coarray", "effective argument", etc in the relevant requirements on programs imposed by the standard in section 8.5.2 - bear in mind the above question is coming from someone who's been working with coarrays for about ten minutes so I might be missing really obvious things.)

While I'm here, some [st]feature requests dressed up as[/st] questions...

- Are you guys considering some sort of "single process/multiple threads" support for coarrays? (That is - something like the way OpenMP is implemented). Debugging a maze of twisty little images, all alike, strikes me as a bit of an adventure.

- What's the rationale for not making "syntax only" support of coarrays the default? (That is - by default the compiler accepts the square bracket syntax and just "hardwires" NUM_IMAGES and THIS_IMAGE or whatever to give one, use the /Qcoarray compiler option to tell the program to go forth and multiply.) Error 8517 has now made my list of compiler messages that I'd like to take out the back one day for a "feedback session".

The thing on the left of the

IanH — Mon, 05 Aug 2013 05:31:45 GMT

The thing on the left of the equals in an assignment statement is a variable and a variable can be a designator and a designator can be a substring and a substring is a parent-string followed by a substring range thing and a parent-string can be a coindexed-named-object. So that means the substring range thing follows the coindexing stuff... correct?

[fortran]PROGRAM LearnMyLetters
IMPLICIT NONE
CHARACTER(26) :: abc

INTEGER :: i
!***
i = THIS_IMAGE()
DO WHILE (i <= LEN(abc))
abc[1](i:i) = ACHAR(IACHAR('A') + i - 1)
i = i + NUM_IMAGES()
END DO

SYNC ALL

IF (THIS_IMAGE() == 1) PRINT "(A)", abc
END PROGRAM LearnMyLetters

[/fortran]

[plain]H:\Projects\Coarrays\LearnMyLetters>ifort /check:all /warn:all /standard-semantics /Qcoarray LearnMyLetters.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.198 Build 20130607
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.

LearnMyLetters.f90(8): error #5082: Syntax error, found '(' when expecting one of: % . = =>
abc[1](i:i) = ACHAR(IACHAR('A') + i - 1)
----------^
compilation aborted for LearnMyLetters.f90 (code 1)[/plain]

but if we switch [1] and (i:i) it compiles.

(If I use that switched order in a actual argument reference, the compiler complains (correctly, I think then).)

Ian,

Steven_L_Intel1 — Mon, 05 Aug 2013 14:20:48 GMT

Ian,

Lots of things here - let me address some of them - the syntax error I will get to a bit later.

No disrespect intended for either Richard Maine or Mike Metcalf, but neither of those two are people I would consider experts on coarrays. Now if Bill Long from Cray had commented, that would be another thing entirely. I had thought there was some discussion of your question on the J3 mailing list, but I guess not. It may yet happen.

My gut feel on this issue is that the whole coarray is meant when discussing "variable" - it is consistent with the way the language treats other variables (consider, for example, the rules on EQUIVALENCE.) The way we generally work it is that we don't look to see what other images have done until we reach a segment boundary (or something else is done that touches a coarray locally. Indeed, we've recently discovered that we're not quite doing this right, in that we allow the local "part" of the coarray, referenced without [], get out of synch with the same part referenced with [], so we have to fix that.

We are not at present considering an alternative to MPI for our coarray implementation - we have enough other things to do to keep us busy!

As for the "syntax only", that's not really what is needed. It would be an alternative library (or lots of special casing in the current one) that skipped the MPI calls. Again, a not-trivial effort for a special case. Maybe someday...

It turns out the parsing

Steven_L_Intel1 — Mon, 05 Aug 2013 14:49:28 GMT

It turns out the parsing issue had been previously reported to us a while ago, with an almost identical program. I wasn't able to get the compiler to give me an error with an actual argument - it allowed me to use both forms without error. Our issue ID on this is DPD200179215 - I attached your test program to it and will let you know when we get it fixed.

Thanks. In usual style I now

IanH — Mon, 05 Aug 2013 15:39:02 GMT

Thanks. In usual style I now cannot work out what/how I saw the actual argument error, but whatever it was - it was what made me realize that the syntax I originally had for the left hand side substring was wrong but not being picked up by the compiler.

If you are party to any further discussion about what "variable" means I'd appreciate any update. I'm not even sure I can spell equivalence.

When you update to 14.0, you

Lorri_M_Intel — Mon, 05 Aug 2013 19:34:40 GMT

When you update to 14.0, you should be able to use the new keyword /Qcoarray:single to squelch your error 8517's. Leave off the "single" to get real coarray behavior.

--Lorri