<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Jun 22, 2011, at 10:48 AM, Jeff Squyres wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Martin --<br><br>It is important to realize the difference between the different Fortran bindings.  <br><br>The "old" form (via include 'mpif.h') will still be available, and (likely) use whatever mechanism an implementation used for it before (e.g., have an underlying symbol for MPI_RECV as mpi_recv, MPI_RECV, mpi_recv_, and/or mpi_recv__).  These will likely also be the same underlying symbols for the "use mpi" interface.<br><br>However, the "use mpi_f08" interface uses different parameter types than mpi.h/use mpi.  So it has a different back-end function for MPI_RECV than the other two.  Modern fortran also allows us to specify what the back-end symbol name will be; hence, Craig is proposing a specific set of back-end symbol names for the "use mpi_f08" functions like MPI_RECV that will be different than those used for mpif.h and "use mpi".  This will actually allow tool authors to know for sure what the symbol names will be.<br><br>So in one sense, we're not breaking tools because the use mpi_f08 interface is new.<br><br>In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future.  Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism?<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>It would eventually be nice to break backwards compatibility regarding Fortran name mangling (lower case, caps, underscores, ...) here by using a standard interface for tools implemented in either C or Fortran.</div><div><br></div><div>-craig</div><div><div><br></div><br><blockquote type="cite"><div><br><br>On Jun 22, 2011, at 12:12 PM, Rasmussen, Craig E wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Jun 20, 2011, at 9:45 PM, Martin Schulz wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Craig, all,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(I cc-ed the tools group on this as well - this is regarding the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">issue how the profiling interface will work with the proposed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">new Fortran bindings):<br></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">On Jun 20, 2011, at 10:15 AM, Rasmussen, Craig E wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I've talked with Jeff Squyres and we come up with naming convention that we'd like to propose for tools to have access to Fortran.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I believe we need four different symbol naming conventions.  Consider MPI_Recv(), the four functions are<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">1. mpi_recv_f<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     - This function implements (in C or Fortran) MPI_Recv with integer handles and the choice buffer passed by address.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Does this mean the existing mpi_recv binding will go away?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This would break any existing tool. Can we keep the old naming<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">scheme for the old interface? Or is this intended as an additional<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">symbol?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hum and YUK.  There really isn't an mpi_recv symbol as the Fortran compilers mangle the name.  We could keep the old mixed up name mangling scheme (and hopefully deprecate it) for the mpif.h usage.  This proposal give the C tools writer a common symbol name hook rather than compiler dependent mangling.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">2. mpi_recv_f_nostatus<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     - This function implements (in C or Fortran) MPI_Recv with integer handles without a status variable and the choice buffer passed by address.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is this just for the new bindings?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">New bindings only but could be made available to "use mpi" users.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">3. mpi_recv_f08<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     - This function implements (in C or Fortran) MPI_Recv with integer handles and the choice buffer passed via an array descriptor.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">4. mpi_recv_f_nostatus<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     - This function implements (in C or Fortran) MPI_Recv with integer handles without a status variable and the choice buffer passed via an array descriptor.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I assume you mean mpi_recv_f08_nostatus?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes.  But Steve requested a name change to mpi_recv_desc and mpi_recv_desc_nostatus.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Note that these functions only need to support integer handles because of the way we (thanks to Rolf) have chosen to define the handle types in the mpi_f08 module.<br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I should say support integer handles in C.  If implemented in Fortran the interface would be with typed Fortran handles for mpi_recv_desc and mpi_recv_desc_nostatus.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-craig<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">mpi3-fortran mailing list<br></blockquote><blockquote type="cite"><a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran</a><br></blockquote><br><br>-- <br>Jeff Squyres<br><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>For corporate legal information go to:<br>http://www.cisco.com/web/about/doing_business/legal/cri/<br><br><br>_______________________________________________<br>mpi3-fortran mailing list<br>mpi3-fortran@lists.mpi-forum.org<br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran<br></div></blockquote></div><br></body></html>