Re: [Mpi-forum] MPI-3 Fortran implementation now available

[Jeffrey Squyres <jsquyres at cisco dot com>]

On Feb 27, 2012, at 5:14 PM, Tobias Burnus wrote:

>> For other Fortran compilers, we're using their proprietary ignore TKR syntaxes
> 
> OK, that explains the difference! It's not a Fortran compliance issue or a bug but just a missing vendor extension.

'zactly. That's why I phrased the blog entry to say: "Gfortran, unfortunately, does not have enough features to support either the new mpi or mpi_f08 modules." -- perhaps that was poor wording on my part; I was not referring to Fortran language features, but rather having an "ignore TKR" syntax.

I can issue a clarification on my blog, if you'd like.  To be clear: I was NOT trying to slam gfortran here.  :-(

> [snip]
> However, once it is implemented, one doesn't is not required to wait for the final release as one can also use the development version. (See for instance http://gcc.gnu.org/wiki/GFortranBinaries) There are some users which regularly use it; it is most of the time rather usable.

Good to know!

> [snip]
> If I have understood dimension(..) correctly, that passes not the bare data but the whole array descriptor (dope vectors). That is: The rank of the array and the dimension triplet (lower bound, stride multiplier and extend). In particular, the array might be noncontiguous (unless the contiguous attribute is used) and the descriptor does not contain the data but just a pointer to the actual data. Dimension(..) contrary to assumed-size or explicit size arrays (cf. above) does accept scalars.

Yes, as you probably surmised from later in the mail, TYPE(*), DIMENSION(*) still isn't sufficient.  Here's why: we have to be able to accept scalars in the buffer argument, too.  We could have a bunch of overloaded interfaces -- one for TYPE(*), DIMENSION(*), and then one for every intrinsic type with a scalar, but then this does not allow derived scalars to be passed.  That's a bummer.

> [snip]
> I see also the additional problem for nonblocking (or worse one-sided communication). Thus, I concur that dimension(..) is useful, but it makes the implementation more difficult for the MPI implementation.

Yeah, but we're a tough bunch.  We can handle it (I hope!).  :-)

>> FWIW, here's our requests, in priority order:
>> 
>> 1. TYPE(*)
>> 2. New ASYNCHRONOUS semantics
>> 3. DIMENSION(..)
> 
> Well, 2 seems to be fulfilled if I understand TS29113, the MPI requirements and GCC's behavior correctly. (We also claim in the 4.7 release notes that GCC is conforming.)
> 
> As written, I think type(*) should be doable without too much effort - thus, I expect that it will get implemented in 4.8.

Great!

> Regarding, dimension(..) and the new array descriptor, I really have no idea. It's definitely planed, but also other features related to polymorphism (FINAL [destructor], unlimited polymorphism) or deferred-length components are highly requested. (As are - to a slightly lesser extend - coarrays or IEEE.)


Fair enough.

-- 
Jeff Squyres
jsquyres@cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/