<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>So what is the state of things regarding LOGICALs?  Is the following summary valid?  Can we take a straw vote on solution paths?</div><div><br></div><div>1. We have to do something about Logical.  Alternative solutions to vote:</div><div>       1a. Kill BIND(C) for interfaces with Logical variables.  Fortran implementations must call C routines from thin wrapper.  Fortran implementers may use modules with thin Fortran wrappers.</div><div>       1b. Replace existing BIND(C) interfaces with Logical variables and use Integer instead of Logical for the dummy arguments.  Overload with a purely Fortran interface using Logical arguments for normal Fortran users.  Implementations must call the BIND(C) interface with Integer arguments for tools usage.  This new interface would have to be renamed so not to clash with existing *_f08 names.</div><div><br></div><div>2. We don't HAVE to do anything else (I assume).  But should we.  Alternatives to vote:</div><div>      2a.  Leave everything else alone.  Use current BIND(C) interfaces for functions not using LOGICAL.</div><div>      2b.  Get rid of BIND(C) altogether.  Require Fortran implementations to call C implementation from thin Fortran wrapper.   Implementers are free to place Fortran wrappers in a module.  This choice allows significant reduction in implementation complexity for MPI library vendors and for tools.</div><div>      2c.  Get rid of most of BIND(C) Fortran interfaces but keep a few that make sense.  Perhaps the routines with callbacks fit in this category.</div><div><br></div><div>3. When to stage the changes?  MPI 3.1 or 4.0?  Alternatives to vote:</div><div>     3a. Make changes as soon as possible.</div><div>     3b.  Change LOGICAL now, wait to do additional changes (if any) until MPI 3.1.</div><div>     3b.  Change LOGICAL now, wait to do additional changes (if any) until MPI 4.0.</div><div><br></div><div>4. Other votes?</div><div><br></div><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><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Mar 21, 2013, at 8:47 AM, Jeff Squyres (jsquyres) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mar 21, 2013, at 8:44 AM, "Schulz, Martin" <<a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>> wrote:<br><br><blockquote type="cite">I feared that this would be the reaction and that were also my original reservations. From a tools perspective this would indeed be the easiest and cleanest solution, but I can see the downside. Implementation effort for rewriting aside (which I realize is important), do you expect a large performance impact, though?<br></blockquote><br><br>I can't speak for NEC.<br><br>The reason we did it this was in OMPI was not for performance -- it was for implementation-specific reasons.  That is, there are some cases where we want to do something different for the Fortran implementation vs. the C implementation.  One obvious example of this is for just about any function involving callbacks.<br><br>MPICH may not have this issue because their handles are always integers, but for OMPI, C handles=pointers/F handles=integers, so we have to do some swizzling/de-swizzling for the conversion.<br><br>-- <br>Jeff Squyres<br><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>For corporate legal information go to: 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>