Attendees: Dave Goodell, Jeff Squyres, Fab Tillier - Failbook, Lamebook, and @BPGlobalPR good time sinks while waiting for folks to call in. - Forum keeps going in circles on how to handle MPI_COUNT, enough so that David Solt gave up. - Discussing this issue for quite some time (started in Portland last November as far as I know, maybe earlier.) - No proposed solution has been satisfactory to the majority of forum members. Summary of proposed solutions to date (please help flush this out, as I am lacking context): 1. Define MPI_COUNT only for MPI-IO functions. Rejected: needs some changes in MPI_Get_count, etc, which have ramifications on other APIs, or introduce new MPI_Get_count_xxx. 2. Define MPI_COUNT for all functions. Rejected: why touch functions were a need hasn't been demonstrated (you can send more than 2^31 elements by creating datatypes.) 3. Define MPI_COUNT for new functions that have some kind of suffix. Rejected: what is the proper suffix, how do you handle exponential growth when you introduce the next suffix, blows up API surface area. Action Items: - Fab: Put together slides for June meeting (short on time, if everyone can send me or point me to slides related to this that were previously presented, please do.) - Quincey, and everyone else: Make sure this is palatable to you - Everyone: help Fab make a good presentation. :) Plan: Propose MPI_COUNT for all functions, define MPI_COUNT as >= int, allowing backward compatibility while also allowing moving forward. No requirement to support either int or >int - that's an implementation choice. Benefits: - lets implementers respond to customer demand without breaking backward compatibility for existing codes (ABI can be kept identical if MPI_COUNT defined as int.) - keeps API surface area manageable for implementers that don't support MPI_COUNT > int. Disadvantages: - doubles test surface area for implementers providing both int and > int implementations - MPI_COUNT > int breaks F77? Jeff says we don't care, as there aren't any F77 compilers anymore, and the F90 and newer compilers are fine with this. - doesn't set precedent for how to handle changes like this in the future. Questions: - Do we allow implementations to provide both int and > int support simultaneously for Fortran using polymorphism? Jeff, Dave, please fill in if I've missed something. -Fab