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 [[email protected]] on behalf of Rolf Rabenseifner [[email protected]] 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)" <[email protected]> To: "MPI Fortran WG" <[email protected]>, "MPI Tool WG" <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Click https://www.mailcontrol.com/sr/j9b8NmH+kWjGX2PQPOmvUi5k6UwC8217mwo9DA!ymB+Y9... to report this email as spam.