[MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()

[Jeff Hammond]

When did Fortran start requiring function declarations?  One of the issues
we might see in legacy Fortran code is use of MPI functions without the
header at all.

Would it be legal to specify the contents of mpif.h be nothing more than
"use mpi"?

Jeff


On Mon, Jul 13, 2020 at 8:53 AM Bill Long <longb at cray.com> wrote:

> Well, as I pointed out, vendors are not going to actually delete old
> stuff.  But that should not be a reason to avoid cleaning up the spec.
>
> There are ways to “fix” the mpif.h problem:
>
> 1) Assuming that the legacy MPI module provides the same capabilities as
> mpif.h, you could jus supply an empty mpif.h file (avoids having to delete
> the include line from the source), and then have a compiler option to
> “auto-use” a module and have the compilation include that option,
> specifying the MPI module.  (Advantage of not changing the actual source
> file.)
>
> 2) Have a program that checks for an include of mpif.h and deleting that
> line and including a USE statement instead that specifies the MPI module.
>  (Disadvantage that the mpif.h file might be included indirectly, by being
> part of another file that is included or part of a user module.)
>
> 3) Same as 2 only check for actual calls to MPI routines or uses of MPI
> data types  in the source file.  I there are none, do not  add the USE MPI
> statement.  Compile with the option that forces IMPLICIT NONE to be sure
> there were no missed references to MPI stuff.
>
> 4) Much more difficult - have a whole program analyzer that would remove
> all of the MPI (and SHMEM) and replace it with the native stuff built into
> Fortran.   Probably the right path for new code, and bets done by a person
> for an old code.
>
> The Cray/HPE Fortran compiler already provides the tools to implement
> option 1.
>
> Cheers,
> Bill
>
>
> > On Jul 10, 2020, at 9:52 PM, Jeff Hammond <jeff.science at gmail.com>
> wrote:
> >
> > To help aid in the depreciation of mpif.h, perhaps Cray/HPE can
> contribute a source-to-source translation tool that can be recommended to
> the MPI user community.
> >
> > Jeff
> >
> > On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran <
> mpiwg-fortran at lists.mpi-forum.org> wrote:
> >
> >
> > > On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) <
> jsquyres at cisco.com> wrote:
> > >
> > >>
> > >> 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still
> included in the spec?  These are embarrassingly obsolete.  If this was
> fixed, none of the above mentioned conversion routines would be needed.
> \end(unpopular}
> > >
> > >
> > > I would love it if we could ditch -- at a minimum -- mpif.h.
> > >
> > > However, there's oodles of legacy code out there that uses it.  That's
> why even deprecating it gets shouted down at Forum meetings.
> >
> > We have the same discussions in the Fortran committee about deleting
> things, or at least making them “obsolescent”, which seems functionally
> similar to deprecated in MPI.   In the end, we specify certain archaic and
> now-redundant features as deleted with full knowledge that implementors
> will not remove the capabilities from compilers because of old codes.
> However, the Intent is to guide programmers writing new code in the
> direction of using the new (hopefully better) alternatives.  And, relevant
> to the present discussion, deleting certain old stuff makes the standard
> document cleaner.
> >
> > Fundamentally, MPI is a C library.  Other languages, like C++ and
> Python, don’t require separate bindings specified in the MPI spec  because
> they can call C library routines.  The whole mpi_f08 module exercise was to
> demonstrate that Fortran can now do the same.  The whole idea of specifying
> a separate Fortran MPI interface needs to be rethought.  Perhaps something
> like
> >
> > “This version of MPI specifies the contents of a vendor-required Fortran
> module for MPI that allows access to the underlying C specification.  The
> separate language binding for Fortran has been deleted, but is still
> available for historical reference in the MPI-3 and earlier specifications.”
> >
> > That should allow for a significant simplification of the MPI
> specification document.
> >
> >
> > Cheers,
> > Bill
> >
> >
> > Bill Long
>        longb at cray.com
> > Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> > Bioinformatics Software Development                      fax:
> 651-605-9143
> > Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite
> 1000/  Bloomington, MN  55425
> >
> >
> >
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran at lists.mpi-forum.org
> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
> > --
> > Jeff Hammond
> > jeff.science at gmail.com
> > http://jeffhammond.github.io/
>
> Bill Long
>      longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite
> 1000/  Bloomington, MN  55425
>
>
>
>

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20200713/229628f7/attachment-0001.html>