On May 16, 2014, at 11:14 AM, Rolf Rabenseifner <[email protected]> wrote:
We need a correct expression telling that it is allowed to be not interceptable.
MPI-3.0 wording: "as macro in C." [does not tell anything about Fortran]
Per my other mail, I think we don't want to touch this in an errata. Allowing WTICK/WTIME to be inlined in Fortran -- which I intentionally avoided in the original proposal -- is a new thing, and should wait until MPI-4. My proposal was amended by your prior mail, but I do not like this "Maybe better proposal" you sent. To be clear, here's what I'm currently proposing: ----- 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.) ----- and ----- 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/