[MPI3 Fortran] Summary of items on the table

[Lionel, Steve]

My personal preference is for choice 4, the IGNORE attribute (the
specific spelling can be debated - I had earlier suggested a VOID
attribute that ignored all of TKR, but whatever works and can be
approved is fine with me.)  There seems to be strong sentiment with some
against such a thing, which I don't fully understand.  I consider the
use of an attribute to be the cleanest approach with the least damage to
the language, and has some precedent in VALUE.  It has the benefit of
mapping closely onto existing practice so it is likely to be picked up
quickly.

Second choice would be #1, mapping to C_PTR.  I agree with Bill's pros
and cons for this option.

My third and fourth choices are very distant from first and second - I
dislike them both almost the same and consider them alien to the
language.  The notion that a specific named type has some magical
properties is pretty much unheard of in Fortran - the only thing that
comes close is that in a BIND(C) routine, an array of single characters
matches a character variable of arbitrary length.

Creating a new datatype C_VOID will cause great upheaval to compilers -
in my experience, adding a new intrinsic type requires extensive changes
and tends to create bugs that remain for years. It also requires
extensive edits to the standard text. Type(C_VOID) is a little better,
except that it is even stranger that one derived type declaration has
special properties.  Today, one can express all of ISO_C_BINDING as
Fortran code, perhaps with some C helper routines, but there's no way to
write type(C_VOID) in ordinary Fortran.

Can one declare variables of these types?  Do I/O?  Storage association?
TRANSFER?

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH 




> -----Original Message-----
> From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-
> bounces at lists.mpi-forum.org] On Behalf Of Craig Rasmussen
> Sent: Monday, April 28, 2008 3:12 PM
> To: MPI-3 Fortran working group
> Cc: Bill Long
> Subject: [MPI3 Fortran] Summary of items on the table
> Importance: Low
> 
> There has been quite a lot of traffic in the past couple of months
> regarding possible directions for a new MPI binding for Fortran.  I
> thought now would be a good time to summarize and try to get a
> consensus on what direction we should pursue.  Some choices will
> require changes to the Fortran standard and this input we need to get
> to the Fortran standards committee within the next two weeks.
> 
> The major choice we need to make is how to declare an MPI "choice
> buffer" (void *) in a Fortran interface.  I'll list the options below
> with advantages and disadvantages as I see them.  Please rank these
> options (they all will use F2003 BIND(C)).
> 
> 1. Map void* to C_PTR.  Upside: this will work now in most compilers
> and likely all soon.  Downside: users must change the call site to
> use C_LOC to obtain the C address; C_LOC requires the POINTER or
> TARGET attribute and may reduce performance and require additional
> code changes.
> 
> 2. Map void* to a new Fortran type C_VOID.  Upside: no changes to
> current code (I think). Downside: would require a change in the
> Fortran standard and couldn't be done until Fortran 20xx (a long time
> before we see it in compilers).
> 
> 3. Map void* to type(C_VOID) defined in the ISO_C_BINDING intrinsic
> module and add LANG=C to the Fortran standard.  Upside: no changes to
> current code other than to USE the MPI3 module.  Downside: it will
> require changes to the Fortran standard but can get to users
> relatively soon (before F2008 appears in compilers).
> 
> 4. Add an IGNORE attribute with parameters T (type) K (kind) R (rank)
> for BIND(C) interfaces.  This pretty much (as I understand it) does
> the same thing as #3, just with different syntax and with slightly
> more flexibility (partial type checking).  Upside: see #3.  Downside:
> see #3.
> 
> Aleks has submitted a proposal to the Fortran J3 committee to improve
> on the ASYNCHRONOUS attribute.  Hopefully this can make it into the
> F2008 standard and fix problems associated with copyin/copyout
> semantics and with code motion associated with asynchronous MPI
> calls.  A question I have is there a problem with copyin/copyout for
> synchronous MPI?
> 
> I'm currently at the April MPI Forum where I'll collect votes.
> Others please add your feedback (rank the options) in email (actually
> it would be helpful for the record to get email from everyone within
> shouting distance).
> 
> A question just came up about passing CHARACTER parameters.  Comments?