<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1760179667;
mso-list-template-ids:683952988;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I vote for #4. This encourages good programming practice
but allows programmers the option of omitting the kind in most circumstances.
The wording of choice 2 is unreasonably restrictive, I believe, unless it is
suggesting that vendors may not provide generics or promotion features.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#0070C0'>Steve Lionel<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#0070C0'>Intel Developer Support<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#0070C0'>Nashua, NH<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
mpi3-fortran-bounces@lists.mpi-forum.org
[mailto:mpi3-fortran-bounces@lists.mpi-forum.org] <b>On Behalf Of </b>Craig
Rasmussen<br>
<b>Sent:</b> Monday, September 14, 2009 1:05 PM<br>
<b>To:</b> MPI-3 Fortran working group<br>
<b>Subject:</b> [MPI3 Fortran] Straw vote on integers kinds<br>
<b>Importance:</b> Low<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>I've fixed the wiki to better represent current thinking and
cleaned up and added example code. I think we are pretty close to having
most of the issues resolved. We still must come to terms with what to do
with integer kinds. In the wiki, I've listed four possibilities; three of
them have come up in recent discussions. I've listed them below, also
see <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage">https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage</a><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Please vote for one of the options. My personal view
is that we need to open up the question to the entire MPI Forum to get reaction
from a larger community (not just Fortran geeks). I'll do this at the
next meeting in Portland.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Use
the default integer kind. This has the least impact on existing codes.
This causes problems when the size of default integers are promoted for
user code and not also in the MPI library.<o:p></o:p></span></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Specify
a named kind, e.g., MPI_INT_KIND. This provides the most specificity and
the user will have a known way to code that will work under all
circumstances. But this will cause problems for existing codes when
compiler options are used that change the size of default integers.<o:p></o:p></span></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Require
the vendor to provide two interfaces, one for standard integers and one
for long integers. This option works when integers are promoted and
doesn't break existing codes.<o:p></o:p></span></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Specify
a named kind in the Fortran interface (MPI_INT_KIND) but allow the vendor
a choice as to how to address integer promotion (it would become a quality
of implementation issue) if users use default integers in their codes. The
vendor could provide an additional interface for promoted integers (not
part of the MPI standard) or could provide a separate library to link
against.<o:p></o:p></span></li>
</ol>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>-----------<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-size:13.5pt;
font-family:"Helvetica","sans-serif"'>I vote for number 4. I believe that
a standard should provide specificity to the programmer. If the
programmer uses MPI_INT_KIND, his/her program will always work even if integers
are promoted or C_INT doesn't match up with default integers. Since users
will have to change existing codes anyway (to use the new derived types, e.g.,
MPI_Comm) users can make the transition to specific kinds at this time.
However, I also think the standard should also leave room for vendors to
provide additional integer kinds via generics or separate compilation
libraries.</span></span><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-size:13.5pt;
font-family:"Helvetica","sans-serif"'>-craig</span></span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>On Sep 2, 2009, at 11:30 AM, Lionel, Steve wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal>Craig wrote:<br>
<br>
<br>
<o:p></o:p></p>
<p class=MsoNormal>I've been back and forth on this (as well as a few others I
think). <o:p></o:p></p>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<p class=MsoNormal>I'm currently leaning toward using default integers.
Primarily <o:p></o:p></p>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<p class=MsoNormal>because to do otherwise could potentially break countless
lines of <o:p></o:p></p>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<p class=MsoNormal>users code. <o:p></o:p></p>
</blockquote>
<p class=MsoNormal><br>
No, it won't, as long as the choice for the MPI integer kind matches C_INT,
which is pretty much universal for default integer in Fortran implementations.
<br>
<br>
Let me try an example.<br>
<br>
module MPI<br>
use, intrinsic :: ISO_C_BINDING<br>
integer, parameter :: MPI_INT_KIND = C_INT<br>
<br>
interface<br>
subroutine MPI_SUB (INTARG)<br>
import ! Makes the definition of MPI_INT_KIND visible here<br>
integer(MPI_INT_KIND), intent(IN) :: INTARG<br>
end subroutine MPI_SUB<br>
end module MPI<br>
<br>
<br>
User code:<br>
<br>
program test1<br>
use MPI<br>
integer SOMEVAR1<br>
call MPI_SUB (SOMEVAR1)<br>
end<br>
<br>
This is the "existing code" case. The compiler will have a kind
for "default integer" - the number chosen for this kind value varies
by implementation (usually 4 but not always) - let's say it's 4 here. For
this combination of Fortran and a "companion C processor", C_INT is
also 4, and thus so is MPI_INT_KIND. The declaration of SOMEVAR1 does not
specify a kind, so it gets "default integer" or 4. No problem
yet.<br>
<br>
Now let's say that this user has decided to compile her Fortran code with an
option that changes the default integer kind to 8 (-i8 or similar). Now
if the above code is compiled, there will be an error because the module,
assuming it wasn't also compiled -i8, defines the argument as INTEGER(4) but
SOMEVAR1 is now INTEGER(8). The user may have had a reason to use -i8 for
other variables and now needs to figure out what to do. She reads the
source of the MPI module, but if it just says INTEGER with no KIND value, she
may be at a loss to figure out what to change. <br>
<br>
If it had been written like this:<br>
<br>
program test2<br>
use MPI<br>
integer(MPI_INT_KIND) SOMEVAR2<br>
call MPI_SUB (SOMEVAR2)<br>
end<br>
<br>
The call with SOMEVAR2 is ok in either case, because the explicit kind
overrides the default integer kind in effect.<br>
<br>
Explicitly specifying the KIND value in the module helps documentation and
encourages, but does not require, the programmer to specify the KIND value in
their own code. It does no harm and does not force coding changes that
wouldn't be needed otherwise. Using explicit kinds also helps make the
code understandable.<br>
<br>
Regarding functions and subroutines, I think I would need a bit more background
on the earlier discussion. I'll be glad to help on this and perhaps a phone
call with you and Jeff would be in order when convenient.<br>
<br>
<br>
Steve Lionel<br>
Intel Developer Support<br>
Nashua, NH<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
mpi3-fortran mailing list<br>
<a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a><br>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran<o:p></o:p></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>