[Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18

[Rajeev Thakur]

Address-sized variables in MPI can be passed from C to Fortran or vice
versa, and I know of no c2f or f2c conversion functions for them. So I think
MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of the same
size at least implicitly.

Rajeev

> -----Original Message-----
> From: mpi-22-bounces_at_[hidden] 
> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave Goodell
> Sent: Friday, March 06, 2009 1:09 PM
> To: MPI 2.2
> Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
> 
> At the last meeting in San Jose, Rolf brought up a good point w.r.t.  
> ticket #18 [1].  Part of the proposal for ticket #18 is to add  
> MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ 
> MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types.   
> Rolf's point was that it isn't defined in the standard 
> whether or not  
> MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same  
> type.  Obviously we cannot define a new predefined datatype  
> corresponding to two different language types.  I believe 
> Rolf's view  
> (correct me if I'm misrepresenting you, Rolf) was that the 
> forum ought  
> to make their equivalence explicit, irrespective of what 
> happens with  
> ticket #18.  I'm ambivalent about this issue, but I need a 
> resolution  
> on it in order to get #18 into a final voteable state.
> 
> So the larger question to the Forum is: Are these types exactly the  
> same between the two languages?
> 
> Looking at MPICH2 it seems that we try to make them the same 
> size but  
> there are some convoluted code paths in the build logic that might  
> result in different sizes.  I would not consider this to be a  
> compelling argument that they are permitted to differ because the  
> logic in question may simply be buggy or never exercised.  
> Does anyone  
> have an example from other MPI implementations where the 
> types do/may  
> differ?  Do any Fortran experts out there know of instances where  
> MPI_ADDRESS_KIND would be different from MPI_Aint?
> 
> As for the impact on ticket #18, there are several ways to deal with  
> this:
> 
> 1) If the Forum decides that the types are always equivalent, 
> add text  
> to that effect (probably in a separate ticket) and otherwise stick  
> with the current proposal.
> 2) If the Forum decides that the type equivalence is undefined, drop  
> the new MPI_AINT/MPI_OFFSET types from the proposal.
> 3) If the Forum decides that the type equivalence is 
> undefined, create  
> four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT,  
> MPI_F_OFFSET (or some such names).
> 4) If the Forum decides that the type equivalence is undefined, make  
> MPI_AINT/MPI_OFFSET only correspond to the C types.
> 
> I'm inclined towards either #1 or #2, depending on what the Forum  
> decides about the type equivalence.  I also can separate the 
> MPI_AINT/ 
> MPI_OFFSET types out into a separate ticket if this becomes too  
> contentious of an issue, but I'd like to keep it together for now  
> since the text changes are easier to describe correctly in just one  
> place.
> 
> -Dave
> 
> [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>