April 2008 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Summary of items on the table
by Aleksandar Donev 30 Apr '08

30 Apr '08

On Monday 28 April 2008 12:12, Craig wrote: > However, I believe I can get the same thing with a assumed > size, rank 1 dummy. At least the compiler I tried allowed me to call > with a rank 2 actual. Yes, this is legal, and called sequence association. This program, for example, is perfectly legal. Copy in/out happens for non-contiguous arguments. If you add target on both the dummy and the actual, and my most recent proposal (meeting 184) gets accepted, there will be guaranteed no copy in/out if the actual is simply-contiguous. program sequence implicit none real, dimension(10,10) :: x real, pointer, dimension(:,:) :: y call sub(x(2,1)) call sub(x) call sub(x(1:3,5:6)) call sub(y) !call sub(y(3,2)) ! Not legal ! y may be non-contiguous contains subroutine sub(x) real, dimension(*) :: x end subroutine end program > Aleks has submitted a proposal to the Fortran J3 committee to improve > on the ASYNCHRONOUS attribute. Hopefully this can make it into the > F2008 standard and fix problems associated with copyin/copyout > semantics and with code motion associated with asynchronous MPI > calls. Craig, what I submitted is a fix to the inconsistent way of handling the asynchronous attribute across argument passing that's been there since Fortran 2003 (I had actually pointed that out during the F2003 CD but back then I assumed there was a reason the words were written as they are, which I now know is not the case). I have not proposed extending the attribute to apply to "user-defined" asynchronous I/O such as the non-blocking communication calls. That is beyond the "integration and fixes" mandate of J3. Proposals for new functionality should be submitted as public comment. I can help you guys prepare the proposal, but it has to be your initiative. Thanks, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: donev1(a)llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Aleksandar Donev 28 Apr '08

28 Apr '08

Bill Long wrote: > I'm guessing that you mean bind(c) interfaces that are limited by a new > LANG="C" specifier to be for functions actually written in C. Yes. > I think the > original option 3 is better than class(*). Yes. I was stating that it behaves, in terms of argument matching and semantics, as if the dummy were CLASS(*), even though it is actually TYPE(C_VOID). Aleks

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Bill Long 28 Apr '08

28 Apr '08

Aleksandar Donev wrote: > On Monday 28 April 2008 12:12, Craig Rasmussen wrote: > > >> 3. Map void* to type(C_VOID) defined in the ISO_C_BINDING intrinsic >> module and add LANG=C to the Fortran standard. >> > > >> 4. Add an IGNORE attribute with parameters T (type) K (kind) R (rank) >> for BIND(C) interfaces. This pretty much (as I understand it) does >> the same thing as #3 >> > Assuming both are restricted to BIND(C) interfaces only, I'm guessing that you mean bind(c) interfaces that are limited by a new LANG="C" specifier to be for functions actually written in C. In general, bind(c) interfaces can, and often are, for routines actually written in Fortran. > an important > difference, in my mind, is that #3 above only addresses TK mismatch. Rank > mismatch, strided arrays, dope vectors, and anything other than type is > covered by existing Fortran rules, whether they be good or bad. It is exactly > as it is for CLASS(*) dummy arguments in Fortran 2003, the only difference is > that no type descriptor would be passed to C, only an address. > CLASS(*) is an enormous beast. Overloading the same syntax with something like "only an address" has two drawbacks I can see. Using the same syntax for such radically different concepts would be confusing to users (and a pain to write into the Fortran standard), and it precludes (however unlikely) that sometime in the future we might want to actually support interoperability of unlimited polymorphic entities. I think the original option 3 is better than class(*). At least the syntax makes it clear what is intended. Cheers, Bill > Aleks > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Aleksandar Donev 28 Apr '08

28 Apr '08

On Monday 28 April 2008 12:12, Craig Rasmussen wrote: > 3. Map void* to type(C_VOID) defined in the ISO_C_BINDING intrinsic > module and add LANG=C to the Fortran standard. > 4. Add an IGNORE attribute with parameters T (type) K (kind) R (rank) > for BIND(C) interfaces. This pretty much (as I understand it) does > the same thing as #3 Assuming both are restricted to BIND(C) interfaces only, an important difference, in my mind, is that #3 above only addresses TK mismatch. Rank mismatch, strided arrays, dope vectors, and anything other than type is covered by existing Fortran rules, whether they be good or bad. It is exactly as it is for CLASS(*) dummy arguments in Fortran 2003, the only difference is that no type descriptor would be passed to C, only an address. Aleks

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Aleksandar Donev 28 Apr '08

28 Apr '08

On Monday 28 April 2008 16:02, Bill Long wrote: > The only thing you skip is > argument conformance checking. It may be the "only thing" for the purposes of the compiler. But for a language, it makes any program which makes such a mismatch ill-defined. This was the whole point of introducing interfaces---to check against bad programs. Explicitly allowing semantically undefined programs is highly dubious, to say the least. I would never support such a proposal. And I am sure all non-vendor people on J3 won't either. Program safety and clarity has always been a goal for those people, and with a good purpose: To provide a check for compiler vendors who vote based on other principles... Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: donev1(a)llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Bill Long 28 Apr '08

28 Apr '08

Craig Rasmussen wrote: > > On Apr 28, 2008, at 2:20 PM, Aleksandar Donev wrote: > >> On Monday 28 April 2008 12:49, Lionel, Steve wrote: >> >>> My personal preference is for choice 4, the IGNORE attribute (the >>> specific spelling can be debated... >>> There seems to be strong sentiment with some >>> against such a thing, which I don't fully understand. >> Steve, I will throw this one back at you. I asked earlier, but never >> got a >> response: >> >> What happens if the dummy (with the IGNORE attribute) is declared as >> INTEGER(4), and things are performed inside that the standard defines >> only >> for 4-byte integers (e.g., some bit packing operation). Then, the >> routine is >> called with a REAL(8) array? What if the array is of a derived type >> of size 1 >> byte? >> >> What specifically will Intel Fortran do? Compile and give results >> that make no >> sense? If so, the standard must have *specific* restrictions on what the >> actual is allowed to be, and what it means. Only illegal cases can be >> left >> without a meaning. >> >> What does Cray do? >> >> If the routine is written in C and has a void* argument, I understand >> how it >> works. But I do not understand how it works if "everything is written in >> Fortran". > > I don't understand either. I assume I must declare a TKR for the > dummy and then tell the compiler to ignore what I have just declared? > What can I do in the Fortran procedure? I can't think of anything > very useful. I can't define it can I. I think we still require LANG=C. The TKR ignore directives (and, I assume a similar attribute) affect only argument checking. Essentially the effect is to suppress error messages. Once inside the subprogram, you treat the dummy argument with the type, kind, and rank it was declared with. The only thing you skip is argument conformance checking. Traditionally these directives have been used in two environments. One is in archaic Fortran subroutines, typically named COPY or MOVE, that just do block memory copies. These were often written with integer arguments, but called with integer, real, or complex arguments. If the element size did not match, the user adjusted the number of elements to be copied. Such routines have no place in modern codes, but they still exist in some dusty decks, and the directive is an easy way to "fix" the code with minimal source changes. The other use of the directives is in interfaces for routines that are written in C that have void * arguments. In other words, like MPI case, which, when you think about it, is just another variant of the COPY/MOVE operations. > > Perhaps I could use IGNORE(R) if the dummy were declared as a rank 1 > array. However, I believe I can get the same thing with a assumed > size, rank 1 dummy. At least the compiler I tried allowed me to call > with a rank 2 actual. Right. And if ignore(tkr) were added to the standard, there would be some limitations. Dummies that were represented by dope vectors would not be reasonable, for example. Cheers, Bill > > Craig > > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Craig Rasmussen 28 Apr '08

28 Apr '08

On Apr 28, 2008, at 3:47 PM, Craig Rasmussen wrote: > The goal is to get rid of "it will work anyway" with the MPI 3 > bindings. I was thinking of using C_F_POINTER to make it standards > compliant. Please ignore this last statement. I made it in haste. Craig

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Craig Rasmussen 28 Apr '08

28 Apr '08

On Apr 28, 2008, at 2:20 PM, Aleksandar Donev wrote: > On Monday 28 April 2008 12:49, Lionel, Steve wrote: > >> My personal preference is for choice 4, the IGNORE attribute (the >> specific spelling can be debated... >> There seems to be strong sentiment with some >> against such a thing, which I don't fully understand. > Steve, I will throw this one back at you. I asked earlier, but > never got a > response: > > What happens if the dummy (with the IGNORE attribute) is declared as > INTEGER(4), and things are performed inside that the standard > defines only > for 4-byte integers (e.g., some bit packing operation). Then, the > routine is > called with a REAL(8) array? What if the array is of a derived type > of size 1 > byte? > > What specifically will Intel Fortran do? Compile and give results > that make no > sense? If so, the standard must have *specific* restrictions on > what the > actual is allowed to be, and what it means. Only illegal cases can > be left > without a meaning. > > What does Cray do? > > If the routine is written in C and has a void* argument, I > understand how it > works. But I do not understand how it works if "everything is > written in > Fortran". I don't understand either. I assume I must declare a TKR for the dummy and then tell the compiler to ignore what I have just declared? What can I do in the Fortran procedure? I can't think of anything very useful. I can't define it can I. I think we still require LANG=C. Perhaps I could use IGNORE(R) if the dummy were declared as a rank 1 array. However, I believe I can get the same thing with a assumed size, rank 1 dummy. At least the compiler I tried allowed me to call with a rank 2 actual. Craig

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Craig Rasmussen 28 Apr '08

28 Apr '08

On Apr 28, 2008, at 2:29 PM, Bill Long wrote: > Aleksandar Donev wrote: >> On Monday 28 April 2008 12:51, Bill Long wrote: >> >> >>> Changing the actual argument to a C_LOC reference also has the side >>> effect of making the actual argument an expression whose value is >>> not a >>> Fortran pointer. Thus, the corresponding dummy argument cannot be >>> defined. A problem for about half of the interesting MPI cases. >>> >> That's a bogus complaint. The actual is a C pointer, and cannot be >> changed, indeed. But its target can be changed through the >> pointer, which is exactly the intent here. >> > > The problem is that the Fortran standard supports those semantics > only for a Fortran pointer, not for a C pointer. I know it "will > work anyway", but that does not mean it is valid. > The goal is to get rid of "it will work anyway" with the MPI 3 bindings. I was thinking of using C_F_POINTER to make it standards compliant. I assume we are talking about intent(out) arguments (MPI_Recv). However, I'm afraid that MPI users will revolt from changing their code in this way and stick with the unsafe "it will work anyway" bindings they have been using for a decade. From preliminary feedback at the MPI Forum meeting the wish would be for bindings that limit the effect on existing code. Craig

1 0

Re: [MPI3 Fortran] Summary of items on the table
by Aleksandar Donev 28 Apr '08

28 Apr '08

Hi, > I don't agree with this. There don't need to be any restrictions. In > effect, it's like the common practice pre-F90 of deliberate argument > mismatches, such as "copy" routines. It's an often-used concept. Not in the Fortran standard. I am sure you've read most of it. Tell me where there is a provision for "do as you please" or "you are on your own". The very first few pages say, "If the standard does not interpret the program, it is illegal", or something along those lines. Standardization is about much more than syntax. It is, in fact, much more about semantics. Leaving the semantics undefined is never OK, IMNSHO. > Would you feel better if the IGNORE attribute was allowed only in > interface bodies and not in procedures? Infinitely better. I would prefer them only in BIND(C) interfaces, but for legacy codes I can see the value in not requiring BIND(C). Best, Aleks

1 0