I once proposed that the standard should have something that can be used for any integer that has a range implied by the address range. MPI_Aint is billed as an address but the problem goes beyond adresses. I thought something like MPI_Sint (Size int) would have been a good idea from day one. I have not thought through the implications of adding MPI_Sint now but it would be as good as MPI_Count for that role and perhaps be applicable to some other cases too. This is just a thought. I do not have time at this point to really dig into what it would mean for the MPI 3 document Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 [email protected] wrote on 06/19/2010 10:47:53 AM:

[image removed]

Re: [Mpi-forum] MPI_Type_size question

William Gropp

to:

Main MPI Forum mailing list

06/19/2010 10:51 AM

Sent by:

[email protected]

Please respond to Main MPI Forum mailing list

The standard doesn't say, but to me, the correct answer would be to return an error with class MPI_ERR_OTHER. This follows the approach of providing reliable failure when there is an error, with the user able to set ERRORS_RETURN and check for the error. Returning MPI_UNDEFINED allows the casual user to ignore the error, which is not the MPI approach to errors.

As to how to fix this, if we insist on backward compatibility, then we need new routines, or we need another new type so that we can do the same MPI_Count trick (which doesn't fix the problem but lets implementations choose between backward compatibility and forward compatibility).

Bill

On Jun 18, 2010, at 11:55 AM, Fab Tillier wrote:

...

Hi Folks,

Looking at putting together the MPI_Count ticket, I ran across the following issue and was hoping to get some guidance. Take the following code, using the current int counts, and assume sizeof(int) == 4, sizeof(MPI_DOUBLE) == 8:

{ MPI_Datatype myType; MPI_Type_contiguous( 1048576, MPI_DOUBLE, &myType );

int size; MPI_Type_size( myType, &size ); }

Should MPI_Type_size return an error, due to overflow? Does size get set to MPI_UNDEFINED and the call succeeds?

Similar issues exist for MPI_Pack with the outsize and position parameters, MPI_Unpack with the insize and position parameters, and MPI_Pack_size with the size parameter.

Lastly, it is my belief that these parameters should really be of type MPI_Aint, but changing this would break backward compatibility. They cannot be of type MPI_Count, since overflow can occur if MPI_Count is defined as a C int. How should the standard handle this?

Thoughts? -Fab

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum