[MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
William Gropp
wgropp at illinois.edu
Thu Jul 16 10:17:55 CDT 2020
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea.
Bill
William Gropp
Director and Chief Scientist, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign
> On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <mpiwg-fortran at lists.mpi-forum.org> wrote:
>
> Thanks Rolf, Hubert, and Bill. It all makes sense.
>
> Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
>
> (only in the mpi_f08 and mpi modules)
>
> This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
>
>
>
>> On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <mpiwg-fortran at lists.mpi-forum.org> wrote:
>>
>> Dear Hubert and Jeff,
>>
>>> Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
>>
>> I expect, we didn't want that mpif.h must include the overloading
>> of the operators .NE. and .EQ. for all TYPE(MPI_....).
>> I'm not sure whether such declaration is allowed outside of a module.
>>
>> The use of mpif.h was already deprecated, i.e., if somebody
>> wants to use mpi_f08 stuff in old code, he or she must
>> first substitute the include mpif.h by use mpi.
>>
>>> ... But it was never intended that the programmer
>>> does this transformation within the old Fortran subroutine (and old Fortran 77
>>> compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in
>>> mpif.h).
>>
>> It was intended that you can convert from old INTEGER variable or array
>> to new TYPE(MPI_...) within source code using the mpi module
>> or using the mpi_f08 module.
>>
>> But we excluded mpif.h because it need not to provide compile-time
>> argument checking and it use is therefore "strongly discouraged".
>> Why should we add something to this "strongly discouraged" mpif.h
>> area.
>>
>> And, to add it in a later version of MPI is simple. To remove it later
>> is not backward compatible. This may be another reason for not
>> adding it to mpif.h
>>
>> Best regards
>> Rolf
>>
>> ----- Original Message -----
>>> From: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
>>> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf at EMEA.NEC.COM>
>>> Sent: Wednesday, July 15, 2020 6:15:58 PM
>>> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
>>
>>> Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
>>>
>>>
>>>
>>> When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for
>>> a smooth transition from Fortran 77 to Fortran 08.
>>>
>>> I.e. if a programmer has changed some functions from old Fortran to Fortran 08
>>> and uses other libraries or subroutines which still use the old Fortran status
>>> as input or output argument, it was possible to transfer the old Fortran status
>>> within the Fortran 08 subroutine. But it was never intended that the programmer
>>> does this transformation within the old Fortran subroutine (and old Fortran 77
>>> compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in
>>> mpif.h).
>>>
>>>
>>>
>>> Hubert
>>>
>>>
>>>
>>>
>>> From: mpiwg-fortran [mailto:mpiwg-fortran-bounces at lists.mpi-forum.org] On Behalf
>>> Of Jeff Squyres (jsquyres) via mpiwg-fortran
>>> Sent: Wednesday, July 15, 2020 5:26 PM
>>> To: MPI Fortran WG <mpiwg-fortran at lists.mpi-forum.org>
>>> Cc: Jeff Squyres (jsquyres) <jsquyres at cisco.com>
>>> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
>>>
>>>
>>>
>>>
>>> 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 < [
>>> mailto:mpiwg-fortran at lists.mpi-forum.org | mpiwg-fortran at lists.mpi-forum.org ]
>>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:longb at cray.com |
>>> 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
>>> [ mailto:jsquyres at cisco.com | jsquyres at cisco.com ]
>>>
>>> _______________________________________________
>>> mpiwg-fortran mailing list
>>> [ mailto:mpiwg-fortran at lists.mpi-forum.org | mpiwg-fortran at lists.mpi-forum.org ]
>>> [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran |
>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jeff Squyres
>>> [ mailto:jsquyres at cisco.com | jsquyres at cisco.com ]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Click [
>>> https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2CvP2Zmks-Y-w2Bv6lGox3acbEaKe314w5W2BPFL9JFA==
>>> |
>>> here ] to report this email as spam.
>>>
>>> _______________________________________________
>>> mpiwg-fortran mailing list
>>> mpiwg-fortran at lists.mpi-forum.org
>>> https://lists.mpi-forum.org/mailman/listinfo/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) .
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20200716/30dfad15/attachment-0001.html>
More information about the mpiwg-fortran
mailing list