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

[Rolf Rabenseifner]

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" <nmm1 at cam.ac.uk>
> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> Cc: mpiwg-tools at lists.mpi-forum.org
> 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
> 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)