About https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428

It is far better to say what you mean, that say something which most people believe is equivalent, because it won't be for all compilers or necessarily so in the future.

Yes, therefore I would like to see a wording like 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 Sections 17.2.4 and 17.2.5, and no others, as macros in C. ***MPI_SIZEOF and PMPI_SIZEOF may also be implemented such that they may not be interceptable.*** Advice to implementors. Implementors should document which routines are implemented as macros ***or otherwise non-interceptable***. (End of advice to implementors.) Advice to users. If these routines are implemented as macros ***or otherwise non-interceptable***, they will not work with the MPI profiling interface. (End of advice to users.) But for an Erratum, it should be a minimal change. Currently, C applications can test wether a MPI_Wtime macro is defined. There is no need to change this. For Fortran, I learnt from these mails, that we Need to scpecify the outcome: non-intereptable. Best regards Rolf ----- Original Message -----

From: "N.M. Maclaren" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: [email protected] Sent: Sunday, May 18, 2014 12:02:32 PM Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled

On May 18 2014, Martin Schulz wrote:

...

I agree with what you are planning to propose, I am not sure, though, the wording is quite right, and with this I mean more the wording in the existing standard: this sound like as if all these functions are still interceptable in Fortran.

What if we say:

An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the handle-conversion functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C or allow them to be inlined.

Advice to implementors. Implementors should document which routines are implemented as macros or are implemented so that they can be inlined. (End of advice to implementors.)

Advice to users. If these routines are implemented as macros or are inlined, they will not work with the MPI profiling interface. (End of advice to users.)

Basically, what you are doing is spelling out what the term 'inline' means in MPI, but it is STILL technically wrong and remains confusing. Lots of compilers generate multiple calling sequences with different properties - that is near-universal for library calls, but isn't rare for highly optimised user ones. Well, those are not inlined, and not interceptable.

That is also true in C and C++, incidentally, where the word 'inline' means two subtly different things, neither of which is particularly close to the concept on 'inlining' being debated in this thread. But that mess originated in C99, where 'inline' had a LOT of opposition on precisely these grounds.

It is far better to say what you mean, that say something which most people believe is equivalent, because it won't be for all compilers or necessarily so in the future.

Regards, Nick Maclaren.

_______________________________________________ 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)