[mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled

[Hubert Ritzdorf]

What does "inlined in Fortran" mean ?
Fortran is not case sensitive; I think 512 macros for MPI_Sizeof in the command
line of Fortran compiler are not the solution.
Do we really want to run a sed (or perl, ...) script on each source file before compilation ?
Or do you think on a new include file ?

Inlining of PMPI_SIZEOF is missing in the proposal (it's mentioned in the text before,
but not in the proposal)

Hubert
________________________________________
From: mpiwg-fortran [mpiwg-fortran-bounces at lists.mpi-forum.org] on behalf of Rolf Rabenseifner [rabenseifner at hlrs.de]
Sent: Friday, May 16, 2014 3:59 PM
To: MPI-WG Fortran working group
Cc: MPI Tool WG
Subject: Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled

Samll updates, see below.

I corrected the page number and I added
 - "or inlined in Fortran", and
 - the status-conversion routines in 17.2.5
   (They were new in MPI-3.0 and we oversaw that they
    have similar quality as handle-conversion routines.
    Major difference, they have an out-argument
    within the argument list.)

Do we also consensus in adding the status-conversions
to the macro+inline-allowence?
Or do we need to spilt these two things?

Rolf

----- Original Message -----
> From: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
> To: "MPI Fortran WG" <mpiwg-fortran at lists.mpi-forum.org>, "MPI Tool WG" <mpiwg-tools at lists.mpi-forum.org>
> Sent: Friday, May 16, 2014 2:44:10 PM
> Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
>
> Fortran and Tools WGs:
>
> (=== this is a bit urgent if we want to get this read at the Chicago
> meeting; the T-2 deadline is this upcoming Monday morning ===)
>
> We seem to have some measure of consensus on the other thread that
> MPI_SIZEOF should not be profiled.
>
> Note, however, that the Tools chapter currently mandates that PMPI_
> versions of all MPI routines must be available (including, for
> example, MPI_WTICK), but the MPI_ versions do not have to be
> replaceable at link time.  I propose adopting this convention for
> MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF).
>
> Does this wording work as a proposal?
>
  MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads:
  (Jeff, you may used a wrong pdf with ther page numbers)
>
> -----
> An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
> PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions
> (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in
> C.
>
> Advice to implementors. Implementors should document which routines
> are implemented as macros. (End of advice to implementors.)
>
> Advice to users. If these routines are implemented as macros, they
> will not work with the MPI profiling interface. (End of advice to
> users.)
> -----
>
> but should read (new text in ***):
>
> -----
> An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
> PMPI_WTIME, PMPI_WTICK, and the handle-
  ***and status-***
> conversion functions
> (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***,
> and no others, as macros in C
  ***or inlined in Fortran***.
> ***MPI_SIZEOF may also be inlined.***
>
> Advice to implementors. Implementors should document which routines
> are implemented as macros ***or otherwise inlined***. (End of advice
> to implementors.)
>
> Advice to users. If these routines are implemented as macros ***or
> otherwise inlined***, they will not work with the MPI profiling
> interface. (End of advice to users.)
> -----
>
> p555:31-37 (first page of the Tools chapter) currently says:
>
> -----
> 1. provide a mechanism through which all of the MPI defined
> functions, except those allowed as macros (See Section 2.6.4), may
> be accessed with a name shift.  This requires, in C and Fortran, an
> alternate entry point name, with the prefix PMPI_ for each MPI
> function in each provided language binding and language support
> method.  For routines implemented as macros, it is still required
> that the PMPI_ version be supplied and work as expected, but it is
> not possible to replace at link time the MPI_ version with a
> user-defined version.
> -----
>
> but should say
>
> -----
> 1. provide a mechanism through which all of the MPI defined
> functions, except those allowed as macros ***or otherwise inlined***
> (See Section 2.6.4), may be accessed with a name shift.  This
> requires, in C and Fortran, an alternate entry point name, with the
> prefix PMPI_ for each MPI function in each provided language binding
> and language support method.  For routines implemented as macros
> ***or otherwise inlined***, it is still required that the PMPI_
> version be supplied and work as expected, but it is not possible to
> replace at link time the MPI_ version with a user-defined version.
> -----
>
> --
> 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
>

--
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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)
_______________________________________________
mpiwg-fortran mailing list
mpiwg-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran


 Click https://www.mailcontrol.com/sr/j9b8NmH+kWjGX2PQPOmvUi5k6UwC8217mwo9DA!ymB+Y9zimQPwQiXZxEjkqqSE01!J!KbynpmRm4uq9tqSB7g==  to report this email as spam.