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

[Rolf Rabenseifner]

Yes, the "allowed as macros" on MPI-3.0 p555:32 
would allow a different mechanism for these routines
that makes them non-interceptable.

If this "non-interceptable" is done by other means 
than macro, then p555:35 "For routines implemented 
as macros, it is still required that the PMPI_ 
version be supplied" would not apply!

It is bad to use different wording for having 
better English quality ;-(

And your are right, my "#ifdef MPI_Wait" says 
therefore nothing.

Do you all agree that wording in 
p19:48 - p20:5 and p555:31-37 is at all inconsistent
and therefore new and useful wording is needed
in this erratum?

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>
> Sent: Monday, May 19, 2014 4:35:10 PM
> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
> 
> On May 19 2014, Rolf Rabenseifner wrote:
> >
> >Bill,
> >
> >your text goes beyond the errata goal.
> >
> >The errata goal was:
> >  - adding the missing Status conversion
> >  - adding MPI_SIZEOF
> >
> >And this works as errata.
> >
> >Your goal is to allow also
> > - Fortran non-interceptable for these routines.
> >
> >Your additional Change is to allow other methods
> >than C macros for C.
> >This would prevent "#ifdef MPI_Wtime".
> >
> >All this would be MPI-4.0 and not MPI-3.0 errata.
> 
> Would it?  I don't know what useful effect you would expect
> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell
> you (reliably) whether or not it can be accessed through the
> profiling interface.  14.2 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.
> 
> Because it says "ALLOWED as macros", MPI_Wtime may not be accessed
> through the profiling interface, whether or not it is implemented
> as a macro.  Doing so is a user error, leading to undefined
> behaviour.
> Therefore, an implementation may implement them as C inline
> functions,
> and would meet all of the requirements of MPI.
> 
> The error is more pervasive than just for Fortran.  Because it did
> not say what it meant, but something that was equivalent under K&R C
> (sic), it wasn't strictly true in C90 and was rendered significantly
> misleading (arguably erroneous) by C99.  And that's the reason that
> some people get very unhappy about the proposed partial fix.
> 
> It's also why the best solution is to regard ALL of the wording as
> an error - which would probably mean starting a new ticket.  But it's
> definitely an error in the wording, not a change.
> 
> 
> 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)