<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Rolf, I'm sorry to say this but it all seems way too complicated to me. There are too many subgroups, options, special cases, ... When things are too complicated, usually this means that something is wrong.</div><div><br></div><div>Therefore I vote for new option 2x:</div><div><br></div><div>There is a problem with the PMPI interfaces for MPI-3 in Fortran. Therefore as an erratum, we pull them from the standard and fix things up in MPI 3.1/4.0. This means that the BIND(C) names are removed AND they are not replaced by anything in the erratum.</div><div><br></div><div>I'm of the strong opinion that while you CAN remove something that is broken in an erratum, you CAN'T replace the old names with a complete hash of NEW names that will be placed in the MPI namespace forever. Furthermore, these proposed NEW names are completely outside of any language standard and will place too many restrictions on how the MPI 3.0 standard must be implemented. For example, you have to be very careful in how you implement the new names, otherwise an aggressive compiler will optimize the calls away and the proposed NEW, NON-STANDARD symbol names, will disappear (i.e., they will never be called).</div><div><br></div><div>I plan on attending the next MPI meeting in June to discuss these issues in front of the full MPI Forum.</div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Craig Rasmussen</div><div>CAS Scientific Programmer</div><div><a href="mailto:rasmus@cas.uoregon.edu">rasmus@cas.uoregon.edu</a></div><div><br></div></div></span></span>
</div>
<br><div><div>On Mar 27, 2013, at 11:57 AM, Rolf Rabenseifner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>After all the replies, I tried to update the list of options.<br>Please answer at the end the list of "straw votes",<br>may be also with "more clarification needed".<br><br>Option 1<br>- #364 as it currently is, as a minimal solution for <br> the LOGICAL problem.<br> #364 removes BIND(C) only for routines with LOGICAL arguments <br> and for all predefined callback routines <br> and on all ABSTRACT INTERFACE definitions for user written callbacks,<br> and all MPI routines that have such callback PROCEDURE <br> dummy arguments.<br> Tools will need to support underscore name<br> mangling forever (even when TS29113 is implemented by compilers) but<br> only on routines with LOGICAL and PROCEDURE arguments, <br> and for all predefined callbacks.<br><br> Pro: It is consistent between Fortran and MPI.<br> I.e., it is the minimal solution that we must do.<br> Con: It has a mix of BIND(C) and non-BIND(C) routine groups<br> which is ugly for the future.<br> Remark: non-BIND(C) will stay there because the callbacks <br> need non-BIND(C) in the moment and this cannot be <br> changed in the future by nice new concepts from <br> the Fortran language standardization.<br><br>Option 2a<br>- #364 plus changing MPI-3.0 page 605 lines 24-30 and <br> page 605 line 47 - page 606 line 6 by also using non-BIND(C),<br> but other linker names:<br> MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e.,<br> buffers are done with C-descriptors and<br> not with void* pointers.)<br> MPI_Send_fd (in the mpi module or mpif.h if <br> MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done<br> there, i.e., with the descriptors.)<br> The real linker name is defined through the compiler's name<br> mangling for these names.<br><br> This means, we remove BIND(C) from all routines. <br> Tools will need to support underscore name mangling <br> for all routines.<br><br> Pro: It is consistent between Fortran and MPI<br> and it is consistent within MPI, i.e., all<br> functionality is done with non-BIND(C) routines.<br> BIND(C) can be still used internally to<br> call MPI_Send_cdesc and MPI_Isend_cdesc.<br> To be fair, implementatiosn will be based mainly <br> on this TS 29113 feature, but only internally.<br> Con: No BIND(C) on the official MPI interface.<br> We urged Fortran to put some features into TS 29113,<br> but we will not use these features, because they<br> are not needed on this internal interface.<br><br>Option 2b<br>- Same as Option 2a, but allow the four options<br> MPI_Send_f08d (mpi_f08 interface with array descriptor for buffers)<br> MPI_Send_fd (mpi and mpif.h with array descriptor for buffers)<br> MPI_Send_f08 (mpi_f08 interface with void *, via IGNORE_TKR etc.)<br> MPI_Send (mpi and mpif.h with void *, via IGNORE_TKR etc.)<br> only for routines in the two routine groups MPI_SEND and MPI_ISEND.<br> For all other routine groups, we provide only the options<br> MPI_Send_f08 (mpi_f08 interface)<br> MPI_Send (mpi and mpif.h)<br> because there are no DIMENSION(..),TYPE(*) buffers.<br><br> Additional Pro: Reduces significantly the routine sets that <br> must be handled with the PMPI interface. <br> No additional Con.<br><br>Option 2c<br>- Same as 2b, but we allow that all routine groups are done with<br> BIND(C), except the callback routine group MPI_COMM_DUP_FN (and also <br> MPI_TEST (with the LOGICAL args), MPI_OP_CREATE, MPI_REGISTER_DATAREP,<br> and MPI_COMM_CREATE_KEYVAL as long as the required Fortran-C support <br> is missing).<br> For this, the following linker names are used, but without <br> name mangling:<br> MPI_Send_f08d (mpi_f08 interface with array descriptor for buffers)<br> MPI_Send_fd (mpi and mpif.h with array descriptor for buffers)<br> MPI_Send_f08 (mpi_f08 interface with void *, via IGNORE_TKR etc.)<br> MPI_Send_f (mpi and mpif.h with void *, via IGNORE_TKR etc.) <br><br> Pro: In long term, when also LOGICAL and Fortran-callback wiil<br> have become interoperable, an implementation can choose <br> to internally implement all in C based on BIND(C), except<br> these 9 predefined callbacks.<br> This is an ideal basis for option 2d.<br> Con: The tools people have more work.<br><br>Option 2d<br>- Same as 2c, but we define one additional small routine group:<br><br> Routine group MPI_STATUS_F2F08 <br> contains MPI_STATUS_F2F08 and MPI_STATUS_F082F.<br><br> Pro: An implementor may want to choose that this routine group is<br> implemented in Fortran with BIND(C) and the C MPI_Status...<br> routines internally call these BIND(C) Fortran routines.<br> Con: One more routine group (a very weak argument). <br><br><br>Option 3:<br>- Option 2 plus the following rule:<br> - The Fortran PMPI interface can be substituted by a <br> wrapper based sulution that internally calls the full <br> MPI C interface.<br> - In this case, the Fortran interface should be hidden<br> to the tools.<br> - For the buffer routines with the new cdesc descriptor,<br> new interfaces are added for the tools people,<br> e.g., MPI_Send_cdesc and MPI_Isend_cdesc.<br><br> Pro: <br> 1. The thin wrappers can be put in a module.<br> 2. Compilers may be able to inline the wrappers for <br> very efficient implementations.<br> 3. Fortran implementations are much simpler because <br> they won't have to directly support PMPI in Fortran.<br> 4. Since the Fortran implementation is substantially <br> less complex, the costs associated with testing, <br> supporting, and maintaining a Fortran <br> implementation will also be reduced.<br> 4. If all MPI implementations eventually choose to call <br> the C API, then the tools community eventually will <br> not have to support underscore name mangling, <br> thus reducing their costs as well.<br><br> Con: An additional new interface for the tools folk.<br> It is not backward compatible for users who really <br> intercept the Fortran MPI interface.<br><br> Open question: Does Option 3 require MPI-3.1 or can it<br> be done as an MPI-3.0 erratum.<br> Pro erratum: One goal of MPI-3.0 mpi_f08 was to allow<br> a fully standardized implementation, i.e., without<br> compiler dependent software (e.g., name mangling).<br> MPI-3.0 was supposed to do this.<br> The Option 3 will keep this quality.<br> It is a change of the PMPI Fortran interface,<br> but MPI-3.0 allows such changes (See removal of C++).<br> It is an erratum that requires at least double-vote,<br> if we allow this also for the mpi module and mpif.h.<br> Con erratum: It is a real change for the user-interface<br> of Fortran's PMPI. <br><br>Therefore:<br>- Option 3a: allowing this only for the mpi_f08 module<br>- Option 3b: allowing it for all three Fortran support methods.<br>- Option 3c: To allow this Option 3 independently for <br> each routine group.<br><br><br>Option 4: <br>(needed for 2c, for all others it is independent)<br>- Substituting in mpi_f08 <br> all CHARACTER(LEN=xxx) <br> by CHARACTER(LEN=1),DIMENSION(xxx)<br> with xxx = a fixed constant.<br><br> As far as I understand, this cannot be done for CHARACTER(LEN=*)<br> because otherwise the MPI routine cannot learn about the length <br> of the string, see, e.g., argv array in MPI_COMM_SPAWN.<br><br> Pro: As far as I understand, this is needed for BIND(C) for the<br> MPI routines that have CHARACTER(LEN=xxx) dummy arguments.<br> Con: Non-consistent solution for a bug in TS29113 that should be <br> fixed in TS29113.<br> The mpi and the mpi_f08 moudlues will be inconsistent<br> to each other.<br> We do not want to change the old mpi module and mpif.h Fortran interface. <br> With current CHARACTER(LEN=xxx), the MPI routine can check at<br> runtime whether the provided actual argument is long enough.<br> With CHARACTER(LEN=1),DIMENSION(xxx), such a check is impossible. <br><br> Bill and Craig, please correct me if I'm wrong. <br> Is this bug fixable in TS29113, or is there a reason, <br> why CHARACTER(LEN=xxx) is not interoperable with C? <br><br>Open questions:<br><br> - Is anybody for Option 1?<br> - If we are doing Option 2, which version is your favorite 2a, 2b, 2c, 2d?<br> - For each Option 2a-d do you say <br> - absolute necessary<br> - is okay for me<br> - is not okay for me<br> - Do you want Option 3?<br> - If yes, do you want 3a, or 3b?<br> - Can we do 3a as erratum (instead of postponing to MPI-3.1)?<br> - Can we do 3b as erratum (instead of postponing to MPI-3.1)?<br> - If yes, do you additionally want 3c?<br> - Do you want Option 4?<br><br>-----------<br><br>My personal answers:<br> - Is anybody for Option 1?<br> ** No, it is to few.<br> - If we are doing Option 2, which version is your favorite 2a, 2b, 2c, 2d?<br> ** I would prefer 2d.<br> - For each Option 2a-d do you say <br> - absolute necessary<br> - is okay for me<br> - is not okay for me<br> ** 2a: absolute necessary<br> ** 2b: absolute necessary<br> ** 2c: is okay<br> ** 2d: is okay<br> - Do you want Option 3?<br> ** Yes<br> - If yes, do you want 3a, or 3b?<br> ** 3b<br> - Can we do 3a as erratum (instead of postponing to MPI-3.1)?<br> ** Yes <br> - Can we do 3b as erratum (instead of postponing to MPI-3.1)?<br> ** Yes <br> - If yes to 3a or b, do you additionally want 3c?<br> ** Yes<br> - Do you want Option 4?<br> ** No, should be done by the Fortran standardization <br> as correction to TS29113.<br><br>Best regards<br>Rolf <br><br><br><br><br><br><br>----- Original Message -----<br><blockquote type="cite">From: "Bill Long" <<a href="mailto:longb@cray.com">longb@cray.com</a>><br></blockquote><blockquote type="cite">To: "Jeff Squyres (jsquyres)" <<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>><br></blockquote><blockquote type="cite">Cc: "Craig Rasmussen" <<a href="mailto:rasmus@cas.uoregon.edu">rasmus@cas.uoregon.edu</a>>, "Rolf Rabenseifner" <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>>, "MPI-3 Fortran working<br></blockquote><blockquote type="cite">group" <<a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a>>, "Hubert Ritzdorf" <<a href="mailto:Hubert.Ritzdorf@emea.nec.com">Hubert.Ritzdorf@emea.nec.com</a>>, "Martin Schulz"<br></blockquote><blockquote type="cite"><<a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>>, "Tobias Burnus" <<a href="mailto:burnus@net-b.de">burnus@net-b.de</a>><br></blockquote><blockquote type="cite">Sent: Wednesday, March 27, 2013 12:03:27 AM<br></blockquote><blockquote type="cite">Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind<br></blockquote><blockquote type="cite">On 3/26/13 11:26 AM, Jeff Squyres (jsquyres) wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">On Mar 26, 2013, at 12:16 PM, Bill Long <<a href="mailto:longb@cray.com">longb@cray.com</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I don't think there is a problem. To accommodate -i8 you have to<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">recompile the MPI module with the -i8 flag set. We've been shipping<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">two mpi modules as long as I can remember; the compiler scripts<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">pick the right one based on how the user code is compiled. Same as<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">how we select the right version of other libraries that also have<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Fortran default type arguments. Within the MPI module source the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">values of MPI_INTEGER and the similar data types for other Fortran<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">default types are set based on detection of the actual sizes of the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">default types (which change with the compiler options). If you are<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">using the module compiled with -i8, MPI_INTEGER will encode the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">information for an 8-byte integer.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But not all Fortran types have corresponding C types (from a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">standards/strict perspective), right? (e.g., logical -- and I'm not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">sure about the various complex types...?) So the MPI implementation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needs to know that it has to create some synthetic / "good enough"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">MPI datatypes based on actual Fortran types.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">...at least, that's what OMPI does...<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What I did was less sophisticated (at least in terms of mpich<br></blockquote><blockquote type="cite">internals). The values for the various handles at page 666 (how<br></blockquote><blockquote type="cite">appropriate) lines 5-10, and 34, and page 667 lines 15-17 are not new.<br></blockquote><blockquote type="cite">I took the values out of the mpich mpif.h files generated for 32-bit<br></blockquote><blockquote type="cite">defaults and 64-bit defaults. Those values are assigned to internal<br></blockquote><blockquote type="cite">constants in the module. The definition of MPI_INTEGER selects between<br></blockquote><blockquote type="cite">the two options depending on KIND(0), and similarly for the others.<br></blockquote><blockquote type="cite">The<br></blockquote><blockquote type="cite">goal is to produce the same values in the module as in the mpif.h<br></blockquote><blockquote type="cite">files,<br></blockquote><blockquote type="cite">only automatically selected based on the default type size specified<br></blockquote><blockquote type="cite">by<br></blockquote><blockquote type="cite">the compiler options used to compile the module.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite">Bill<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite">Bill Long <a href="mailto:longb@cray.com">longb@cray.com</a><br></blockquote><blockquote type="cite">Fortran Technical Support & voice: 651-605-9024<br></blockquote><blockquote type="cite">Bioinformatics Software Development fax: 651-605-9142<br></blockquote><blockquote type="cite">Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101<br></blockquote><br>-- <br>Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner">www.hlrs.de/people/rabenseifner</a><br>Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br></div></blockquote></div><br></body></html>