[MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)

[Bill Long]

On Jun 12, 2014, at 2:19 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:

> On Jun 11, 2014, at 4:25 PM, Bill Long <longb at 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 at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

Bill Long                                                                       longb at 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