[Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools
Hubert.Ritzdorf at EMEA.NEC.COM
Mon Jun 27 07:31:40 CDT 2011
It's not simply a re-compilation if you add all interface descriptions to mpif.h in order to change the interface names. In addition to the backward compatibility problem, nobody can guarantee that the re-compilation works independent on compiler bugs or other problems.
>From: mpi3-tools-bounces at lists.mpi-forum.org [mailto:mpi3-tools-
>bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
>Sent: Friday, June 24, 2011 6:46 PM
>To: MPI-3 Fortran working group
>Cc: MPI3 Tools
>Subject: Re: [Mpi3-tools] [MPI3 Fortran] MPI function symbol naming
>convention for tools
>On Jun 24, 2011, at 12:20 PM, Hubert Ritzdorf wrote:
>> There are (compiled) libraries and object files containing the
>corresponding external references to MPI_SEND, mpi_send__, mpi_send_ or
>mpi_send. Therefore, you cannot simply change the interface of the MPI_Send
>routine without breaking these libraries. You can also not simply expect
>that they will be recompiled.
>I think it is reasonable to ask applications / libraries / etc. to
>recompile with MPI-3. This has been the position of the Forum.
>> In addition, the mpif.h include file doesn't have an interface block (and
>will still generate the external references above)
>It's actually not specified, right? Meaning that an implementation *could*
>use an interface block if they wanted to.
>> and Fortran 90 module doesn't have an optional error argument in the
>interface block even if you expect that the Fortran 90 module/compiler
>supports some NO_ARG_CHECK attribute.
>We didn't add optional arguments to any of the existing MPI Fortran
>interfaces -- optional arguments are only (possibly) being added in the new
>jsquyres at cisco.com
>For corporate legal information go to:
>Mpi3-tools mailing list
>Mpi3-tools at lists.mpi-forum.org
>6Ug9oI5ig5!3Uqc1BfKxnNutHdm6V!yFfmYpsSvVwQ== to report this email as spam.
More information about the mpiwg-tools