<div dir="ltr"><div class="gmail_extra"><br>
<br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 1:52 PM, Bill Long <span dir="ltr"><<a href="mailto:longb@cray.com" target="_blank">longb@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On Mar 17, 2014, at 1:39 PM, Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov">jczhang@mcs.anl.gov</a>> wrote:<br>
<br>
><br>
</div><div class="">> On Mon, Mar 17, 2014 at 11:52 AM, Craig Rasmussen <<a href="mailto:rasmus@cas.uoregon.edu">rasmus@cas.uoregon.edu</a>> wrote:<br>
> Jeff and I had a similar conversation last week.  It is my viewpoint that the MPI-3 interfaces are formal interfaces that can be adapted by an implementation in a way that formally meets the specification.<br>
><br>
> +1 for this view.<br>
><br>
> For Open MPI I believe that Jeff will add configuration magic to check is INTEGER(C_INT) and default INTEGER have the same KIND value.  This should be true for 100% of the compilers.  If not, then that compiler will not be able to build Open MPI.<br>

><br>
> Supporting different INTEGER and c_int 1) is useless;  2) adds code complexity; 3) adds extra runtime overhead (in MPICH implementation) even when INTEGER and c_int are the same.  I prefer stopping the support and doing configuration time check.<br>

><br>
<br>
</div>There is a problem with this approach.  If the normal INTEGER and c_int are the same, then INTEGER compiled with a switch like -i8 is almost assured to be different from c_int.   It is not that hard to write the module such that a single source can be used to compile both -i4 and -i8 versions.  There should not be measurable overhead with this, since the checks are all on compile-time constants, so the checks and the “unused” branch of the test will be eliminated by the compiler.<br>
</blockquote><div><br></div><div>The compiler eliminates the unused branch in an MPI implementation at the library build time. But later, you use a different sized INTEGER at user code compilation time (through mpif90 options?). That is erroneous. </div>
<div>Why there is runtime overhead when INTEGER = c_int, see my previous reply to Rolf on comparison of designs with INTEGER MPI_Status or with INTEGER(c_int) MPI_Status. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Note that the -i4/-i8 problem is one of the arguments why using default INTEGER in the Fortran interfaces should have been prohibited  by the MPI spec.<br>
<br>
Cheers,<br>
Bill<br>
<div class="im HOEnZb"><br></div></blockquote></div><br></div></div>