# [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()

William Gropp wgropp at illinois.edu
Wed Jul 15 10:37:41 CDT 2020

I’m ok with a clarification that excludes TYPE(MPI_Status) from mpif.h , as Rolf proposes.

Bill

William Gropp
Director and Chief Scientist, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign

> On Jul 15, 2020, at 10:25 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <mpiwg-fortran at lists.mpi-forum.org> wrote:
>
> Just to bring this thread back on-track about TYPE(MPI_Status)...
>
> Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
>
> On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
> MPI-3.1
> - page 607 lines 18-24 require these types and the overloaded
>   operators .EQ./.NE. for mpi_f08 module
> - page 609 lines 34-36 require these types and the overloaded
>   operators .EQ./.NE. for mpi module
> - there is no such text on page 611-612 on mpif.h
>
> And page 802 lines 9-15 also Show that it was never intented to add
> These types anf routines to old mpif.h.
>
> It would be helpful, to add at least on page 657 line 11
>
> C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
>
> Can you fix this with an one-vote-bug-fix-issue?
> Because it is not good if the information must be taken from the change-log.
>
> ---
> Summary:
>
> Does this mean that TYPE(MPI_Status)
> [ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
> needs to be defined in
>
> - mpif.h?    NO
> - and the mpi module?    YES
>
> Bug-fix needed in MPI-3.1 page 657 line 11: add
> "(only in the mpi_f08 and mpi modules)" at the end.
>
> I hope this helps.
>
> Best regards
> Rolf
>
> So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
>
> I'm a little curious as to why we conspicuously left it out of mpif.h.
>
> Bill: this is somewhat counter to the clarification you proposed.
>
> Are you ok with this?  I think the text in the standard supports what Rolf proposes.
>
>
>
>> On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <mpiwg-fortran at lists.mpi-forum.org <mailto:mpiwg-fortran at lists.mpi-forum.org>> wrote:
>>
>> On Jul 10, 2020, at 11:18 AM, Bill Long <longb at cray.com <mailto:longb at cray.com>> wrote:
>>>
>>> In the “change” section there is this txt:
>>>
>>> • Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
>>
>> Good point.
>>
>> Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
>>
>> That being said:
>>
>> - the changelog is non-binding ...but it does indicate our intent from that time
>> - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
>>
>>> 1) Why would the F08 status be defined different from the C definition?  (If that were the case, conversions between f08 and C would be irrelevant).
>>
>> I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
>>
>> I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it.  Perhaps we wanted to allow implementations to do whatever they wanted...?  (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
>>
>>> 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec?  These are embarrassingly obsolete.  If this was fixed, none of the above mentioned conversion routines would be needed.  \end(unpopular}
>>
>>
>> I would love it if we could ditch -- at a minimum -- mpif.h.
>>
>> However, there's oodles of legacy code out there that uses it.  That's why even deprecating it gets shouted down at Forum meetings.
>>
>> --
>> Jeff Squyres
>> jsquyres at cisco.com <mailto:jsquyres at cisco.com>
>>
>> _______________________________________________
>> mpiwg-fortran mailing list
>> mpiwg-fortran at lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
>
>
> --
> Jeff Squyres
> jsquyres at cisco.com <mailto:jsquyres at cisco.com>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20200715/b47a22f2/attachment.html>