[MPI3 Fortran] Argument data sizes (was: Teleconference Wednesday, Sept. 17: Summary)

[Jeff Squyres]

On Sep 17, 2008, at 4:46 PM, Craig Rasmussen wrote:

>> For what it's worth, Fortran compilers already have to deal with  
>> the interaction of modules and default=64 switches.  For example,  
>> the intrinsic iso_fortran_env module contains named constants  
>> (numeric_storage_size, for example) that have different values  
>> depending on these compiler switches.  At least in our case, we  
>> have separate modules that are stored in library subdirectories  
>> with names like 'default64'. The compiler driver knows which place  
>> to look depending on the command line options.  This works for  
>> "known" modules that are supplied along with the compiler (as  
>> opposed to user created modules).  Clearly it is possible to make  
>> the MPI module(s) known in this sense.  (In fact, we do this for  
>> MPI already on our systems.)
>
> Would this work for a third person library like OpenMPI?
>
> If two interfaces are supplied, one for 4 byte integers and one for  
> 8 byte integers, what happens when the compiler switch to go to  
> longs is chosen.  Does the compiler call the 8 byte kind version?  I  
> believe if we go this route, we can't have a default integer  
> interface because it would collide with the 8 byte integer version  
> if the default64 switch is thrown.


Isn't it meaningless to use INTERGER*8 parameters (e.g., the count to  
MPI_SEND) if the MPI doesn't support them (because the MPI spec says  
that the count is a C int)?

I can see the argument of "use a compile flag to change all your  
INTEGERs to INTEGER*8", but per Bill's argument, doesn't that imply  
that users will expect that they can pass an MPI_SEND count value that  
is too large to be held in an INTEGER?  Since the back-end MPI doesn't  
support it (since MPI mandates that counts are C int's), it won't work.

We can *tell* users that the type can be INTEGER*8 but they can't pass  
in values larger than can be held in an INTEGER, but I somehow doubt  
that this will work...  :-)

-- 
Jeff Squyres
Cisco Systems