June 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Rolf Rabenseifner 13 Jun '14

13 Jun '14

Back to MPI_SIZEOF in mpif.h: A few clarifications: 1) The interface of Argument x was not changed between MPI-2.0, 2.1, 2.2 and MPI-3.0: It is always "<type> x" for mpif.h, i.e., without a dimension. 2) The requirement of having this function in mpif.h was changed: MPI-2.0 through 2.2 requiered MPI_SIZEOF in mpif.h "unless the target compiler does not support modules or KIND-parametrized types." This restriction was removed. 3) In general, MPI-2.0 was defined for Fortran 77, but then without, the routines MPI_SIZEOF, MPI_TYPE_MATCH_SIZE, MPI_TYPE_CREATE_F90_REAL/COMPLEX/INTEGER, and without the module mpi MPI-3.0 does not define such a subset. For Fortran 77, it says on MPI-3.0, page 609 line 47: Only MPI-1.1, MPI-1.2 and MPI-1.3 can be implemented. ... 4) We do not have correct rules for PMPI interception of MPI_SIZEOF because it must be implemented through overloading. 5) The other routines in the former "Extended Fortran Support" do not cause such problems. How to solve these problems? I would expect that we should add two errata: A) MPI_SIZEOF needs not to be interceptable, the idea of ticket #428. B) The Fortran 77 rule on p609:47 - p610:2 should be extended to allow mpif.h with all MPI-3.0 routines that are defined with an mpif.h interface, but with the exception of MPI_SIZEOF, because MPI_SIZEOF is the only routine that requires (several overloaded) INTERFACE specifications, which did not came before Fortran 90. Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Thursday, June 12, 2014 9:19:27 PM > Subject: Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question) > > On Jun 11, 2014, at 4:25 PM, Bill Long <longb(a)cray.com> wrote: > > >> Actually, this doesn't work, either. If you have an mpif.h that > >> contains an "INTERFACE MPI_Sizeof", the compiler will treat it > >> differently depending on whether it is included from source.f or > >> source.f90 (and probably other variants, too). Gaahhh! > > > > Not sure why you say this. Unless the lines get too long because > > of long names, you can write an include file so that it works for > > both fixed and free source forms. The assumed source form is the > > only distinction to the compiler between source files that end in > > .f and .f90. > > Argh -- my Fortran ignorance rears its ugly head. Yes, indenting > properly makes that problem go away. > > It's a tight squeeze, but the longest interface I can find is with > COMPLEX(REAL128) and DIMENSION for 15 ranks; it barely fits into 72 > columns: > > COMPLEX(REAL128),DIMENSION(1,1,1,1,1,1,1,1,1,1,1,1,1,1,*)::x > > Quite ugly, of course. But with a perl script to generate all the > possibilities (for maximum portability), it works. Yuck. > > > As you might recall from earlier conference calls, I prefer that > > nothing be added to mpif.h that was not there before. None of the > > new functions or constants. It should be frozen at MPI 2.2 for > > compatibility with legacy codes. If programmers want to use new > > features, they have to modify their sources anyway, and should > > change to using a module at the same time. > > There was unfortunately pushback from the Forum on this issue; we > lost that battle. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by N.M. Maclaren 13 Jun '14

13 Jun '14

On Jun 13 2014, Rolf Rabenseifner wrote: > >Only a remark on the impossibility of >continuation lines in mpif.h: > >MPI-3.0 Errata from May 14, 2014, page 13, lines 38-43 tell: > >"In principle, continuation lines would be possible in mpif.h >(spaces in columns 73-131, & in column 132, and in column 6 >of the continuation line) but this would not be valid if the >source line length is extended with a compiler flag to 132 >characters. Column 133 is also not available for the >continuation character because lines longer than 132 >characters are invalid with some compilers by default." That's wrong in several respects. Lines of other than EXACTLY 72 characters are invalid in fixed form, and ones of long than 132 in free form. But, pragmatically, it's close enough to what compilers do - however, it's also irrelevant. The point is that ALL such mechanisms are outside the standard, and always have been (even in Fortran 66). Perhaps the sanest way to resolve this is that the compilation command or compiler modifies the search path for inclusions according to the source form. But there is almost always a mechanism. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Rolf Rabenseifner 13 Jun '14

13 Jun '14

Only a remark on the impossibility of continuation lines in mpif.h: MPI-3.0 Errata from May 14, 2014, page 13, lines 38-43 tell: "In principle, continuation lines would be possible in mpif.h (spaces in columns 73-131, & in column 132, and in column 6 of the continuation line) but this would not be valid if the source line length is extended with a compiler flag to 132 characters. Column 133 is also not available for the continuation character because lines longer than 132 characters are invalid with some compilers by default." Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Thursday, June 12, 2014 9:33:26 PM > Subject: Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question) > > > On Jun 12, 2014, at 2:19 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com> wrote: > > > On Jun 11, 2014, at 4:25 PM, Bill Long <longb(a)cray.com> wrote: > > > >>> Actually, this doesn't work, either. If you have an mpif.h that > >>> contains an "INTERFACE MPI_Sizeof", the compiler will treat it > >>> differently depending on whether it is included from source.f or > >>> source.f90 (and probably other variants, too). Gaahhh! > >> > >> Not sure why you say this. Unless the lines get too long because > >> of long names, you can write an include file so that it works for > >> both fixed and free source forms. The assumed source form is the > >> only distinction to the compiler between source files that end in > >> .f and .f90. > > > > Argh -- my Fortran ignorance rears its ugly head. Yes, indenting > > properly makes that problem go away. > > > > It's a tight squeeze, but the longest interface I can find is with > > COMPLEX(REAL128) and DIMENSION for 15 ranks; it barely fits into > > 72 columns: > > It is possible to have continuation lines by putting & in column 73 > of the line to be continued (which fixed-source rules will see in > the “comment” part of the line, and free-source will see as a > continuation sentinel) and also a & in column 6 of the following > continuation line (which fixed-source rules will see as the normal > continuation character, and free-source allows and represents > removal of any spaces between the two & characters). This CAN get > foiled if the fixed-source compilation violates the “column 73-80 is > a comment” rule by specifying a longer length for statement content. > Some compilers do allow that. You can help avoid that by moving the > trailing & out farther - say column 132. But there is always some > risk from non-conforming compilers. > > > > > COMPLEX(REAL128),DIMENSION(1,1,1,1,1,1,1,1,1,1,1,1,1,1,*)::x > > > > Quite ugly, of course. But with a perl script to generate all the > > possibilities (for maximum portability), it works. Yuck. > > > >> As you might recall from earlier conference calls, I prefer that > >> nothing be added to mpif.h that was not there before. None of > >> the new functions or constants. It should be frozen at MPI 2.2 > >> for compatibility with legacy codes. If programmers want to use > >> new features, they have to modify their sources anyway, and > >> should change to using a module at the same time. > > > > There was unfortunately pushback from the Forum on this issue; we > > lost that battle. > > I seem to recall. But I interpreted the question as for what was > desired for MPI 4.0, and my opinion on that question is still the > same as before. > > Cheers, > Bill > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long > longb(a)cray.com > Fortran Technical Suport & voice: > 651-605-9024 > Bioinformatics Software Development fax: > 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by N.M. Maclaren 12 Jun '14

12 Jun '14

On Jun 12 2014, Jeff Squyres (jsquyres) wrote: > > Technically, a character and a logical have numerical values, but that's > not how they're generally used. Not in Fortran, they don't! There have been plenty of Fortrans where the latter didn't, and almost certainly some where the former didn't. The value returned from ICHAR is not required to be the 'value' of the datum, and certainly wasn't on systems with parity characters (assuming that any had Fortran 77 compilers). I can't remember if any System/370 compiler supported only the defined EBCDIC characters (before the 8 bit code page extensions), but that would be another example. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Jeff Squyres (jsquyres) 12 Jun '14

12 Jun '14

On Jun 12, 2014, at 3:37 PM, Bill Long <longb(a)cray.com> wrote: >> Quick question on this: (I don't think any of us disagree -- this language includes both scalars and arrays) Does this include logicals and characters? The language says *numeric* intrinsic type. > > The Fortran language is unambiguous on this issue: > > "Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric types are integer, real, and complex. The nonnumeric intrinsic types are character and logical." Sweet; thank you. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Bill Long 12 Jun '14

12 Jun '14

On Jun 12, 2014, at 2:22 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 10, 2014, at 4:55 PM, William Gropp <wgropp(a)illinois.edu> wrote: > >> On SIZEOF, the language in the standard for the argument is >> >> a Fortran variable of numeric intrinsic type (choice) >> >> [snip] >> Thus, I believe that MPI_SIZEOF has the same choice parameter requirements of the communication routines such as MPI_SEND. > > Quick question on this: (I don't think any of us disagree -- this language includes both scalars and arrays) Does this include logicals and characters? The language says *numeric* intrinsic type. > The Fortran language is unambiguous on this issue: "Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric types are integer, real, and complex. The nonnumeric intrinsic types are character and logical." I assumed that is what was meant here. Cheers, Bill > Technically, a character and a logical have numerical values, but that's not how they're generally used. > > Bill: do you remember the intent of the word "numeric" here? > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Bill Long 12 Jun '14

12 Jun '14

On Jun 12, 2014, at 2:19 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 11, 2014, at 4:25 PM, Bill Long <longb(a)cray.com> wrote: > >>> Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! >> >> Not sure why you say this. Unless the lines get too long because of long names, you can write an include file so that it works for both fixed and free source forms. The assumed source form is the only distinction to the compiler between source files that end in .f and .f90. > > Argh -- my Fortran ignorance rears its ugly head. Yes, indenting properly makes that problem go away. > > It's a tight squeeze, but the longest interface I can find is with COMPLEX(REAL128) and DIMENSION for 15 ranks; it barely fits into 72 columns: It is possible to have continuation lines by putting & in column 73 of the line to be continued (which fixed-source rules will see in the “comment” part of the line, and free-source will see as a continuation sentinel) and also a & in column 6 of the following continuation line (which fixed-source rules will see as the normal continuation character, and free-source allows and represents removal of any spaces between the two & characters). This CAN get foiled if the fixed-source compilation violates the “column 73-80 is a comment” rule by specifying a longer length for statement content. Some compilers do allow that. You can help avoid that by moving the trailing & out farther - say column 132. But there is always some risk from non-conforming compilers. > > COMPLEX(REAL128),DIMENSION(1,1,1,1,1,1,1,1,1,1,1,1,1,1,*)::x > > Quite ugly, of course. But with a perl script to generate all the possibilities (for maximum portability), it works. Yuck. > >> As you might recall from earlier conference calls, I prefer that nothing be added to mpif.h that was not there before. None of the new functions or constants. It should be frozen at MPI 2.2 for compatibility with legacy codes. If programmers want to use new features, they have to modify their sources anyway, and should change to using a module at the same time. > > There was unfortunately pushback from the Forum on this issue; we lost that battle. I seem to recall. But I interpreted the question as for what was desired for MPI 4.0, and my opinion on that question is still the same as before. Cheers, Bill > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Jeff Squyres (jsquyres) 12 Jun '14

12 Jun '14

On Jun 10, 2014, at 4:55 PM, William Gropp <wgropp(a)illinois.edu> wrote: > On SIZEOF, the language in the standard for the argument is > > a Fortran variable of numeric intrinsic type (choice) > > [snip] > Thus, I believe that MPI_SIZEOF has the same choice parameter requirements of the communication routines such as MPI_SEND. Quick question on this: (I don't think any of us disagree -- this language includes both scalars and arrays) Does this include logicals and characters? The language says *numeric* intrinsic type. Technically, a character and a logical have numerical values, but that's not how they're generally used. Bill: do you remember the intent of the word "numeric" here? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Jeff Squyres (jsquyres) 12 Jun '14

12 Jun '14

On Jun 11, 2014, at 4:25 PM, Bill Long <longb(a)cray.com> wrote: >> Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! > > Not sure why you say this. Unless the lines get too long because of long names, you can write an include file so that it works for both fixed and free source forms. The assumed source form is the only distinction to the compiler between source files that end in .f and .f90. Argh -- my Fortran ignorance rears its ugly head. Yes, indenting properly makes that problem go away. It's a tight squeeze, but the longest interface I can find is with COMPLEX(REAL128) and DIMENSION for 15 ranks; it barely fits into 72 columns: COMPLEX(REAL128),DIMENSION(1,1,1,1,1,1,1,1,1,1,1,1,1,1,*)::x Quite ugly, of course. But with a perl script to generate all the possibilities (for maximum portability), it works. Yuck. > As you might recall from earlier conference calls, I prefer that nothing be added to mpif.h that was not there before. None of the new functions or constants. It should be frozen at MPI 2.2 for compatibility with legacy codes. If programmers want to use new features, they have to modify their sources anyway, and should change to using a module at the same time. There was unfortunately pushback from the Forum on this issue; we lost that battle. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by N.M. Maclaren 12 Jun '14

12 Jun '14

On Jun 10 2014, William Gropp wrote: > > The problem is that the standard also requires MPI_SIZEOF to be supported > by every version of the Fortran interfaces, even mpif.h. This was *not* > the case in MPI-2. The standard even acknowledges that MPI_SIZEOF > requires overloading, and that overloading definition is required in > mpif.h . Thus, mpif.h cannot be implemented in a way that supports a > Fortran 77 compiler. Another problem, that does not seem to have been raised, is that MPI_Sizeof is potentially unimplementable without a compiler extension in Fortran 77. There is no way of passing arguments that forbids copy-in/copy-out, and it is perfectly permissible for a compiler to change the storage representation for argument passing. I can't remember offhand if any did or does, but it wouldn't surprise me if some did or even do for scalar arguments. The same is true for C, incidentally, and was even more common with that. Quite a few compilers did weird and wonderful things with arguments. Even using interface blocks requires the library to know far more about the compiler and its options (and that's the gotcha!) than is decent. Regards, Nick Maclaren.

1 0