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

[Tobias Burnus]

On 02/28/2012 01:42 PM, Jeffrey Squyres wrote:
> '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. :-( 

Well, I didn't see it as slamming, but I was just curious to know what 
was missing.

>> If I have understood dimension(..) correctly [...]
> 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.

Is there a reason for not using "type(*) ::" for scalars and "type(*), 
dimension(*)::" for arrays? Off hand, I think it should work - and one 
has only two interfaces instead of 1 + (number of intrinsic types) - and 
derived types should work as well.

[gfortran has several intrinsic types/kinds: up to 5 integer and 5 
logical (kind: 1,2,4,8,16), 4 real and 4 complex (4,8,10,16), and two 
character (1, 4) intrinsic types. The number might grow in future due to 
decimal floating-point numbers and more character kinds.]

>>> As written, I think type(*) should be doable without too much effort - thus, I expect that it will get implemented in 4.8.
> Great!

Attached a patch of a rough and dirty implementation of TYPE(*). It 
should work, but it lacks several constraint checks - in particular for 
the actual argument and for the using assumed-type variables. There 
might be also issues with ambiguity checking for generic interfaces.

If you compile GCC 4.7 yourself, you should be able to experiment with 
TYPE(*).


On 02/28/2012 01:50 PM, Richard Guenther wrote:
> On Tue, Feb 28, 2012 at 1:42 PM, Jeffrey Squyres<jsquyres@cisco.com>  wrote:
>>> 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.
> But wouldn't a vendor extension TYPE (*), __gfortran3_dimension (..) be
> also ok that passes the existing descriptor?  The MPI implementation would
> just need to know its specification?  [the '3' for the library SO version, which
> I assume correlates with the descriptor "version"]

I think there are two issues: Implementing dimension(..). And 
implementing the array descriptor as defined in TS29113.

Implementing dimension(..) might be relatively simple, I have not 
studied the standard. But for a library implement like Open MPI it is 
much easier to use the compiler's C header file "ISO_Fortran_binding.h" 
together with well-defined macros and field names than a 
compiler-specific, rather undocumented descriptor format. Especially, as 
the bounds are specified differently (ubound vs. extend and stride vs 
stride multiplied).

But gfortran might indeed first implement dimension(..) with the current 
descriptor. (See also http://chasm-interop.sourceforge.net/ for a 
library which helps to deal with vendor-specific array descriptors.)


In gfortran, a new array descriptor is not only needed for TS29113. It 
is needed for some types of pointers to arrays and it needed to support 
more than 7 array dimensions - Fortran 2008 allows 15. If a new 
descriptor wouldn't break the ABI, we had already done it. As we need 
already need a new descriptor, it makes sense to use internally the same 
as the one of TS29113.

For the new descriptor, not only the new format needs to be implemented 
but also all array-bound-related algorithms modified (in the library and 
in the compiler front end). Implying a lot of changes and testing. 
Additionally, it should be finished early to have time for further clean 
ups and to find regressions. That's the reason that the project has 
already been deferred a couple of years. Compared with other features, 
it is quite a lot of work for little gain.

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assumed-type.diff
Type: text/x-patch
Size: 4554 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20120228/df367ffc/attachment.bin>