Thanks, Jeff. The four levels sounds good to me. — Pavan On Mar 12, 2014, at 11:57 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
FWIW, we had a similar discussion in OMPI this morning. We (loosely) came up with the the following:
1. Have a configure argument to enable/disable having the deleted functions in mpi.h and the mpi module (remember that these deleted functions have no interfaces in the mpi_f08 module -- whew! ...but we'll have to see if anything gets deleted in MPI-4). At least for a while, default to having the interfaces available/compiled in. Eventually, change the default to not having them available/compiled out.
2. When the interfaces are available/compiled in, have a run-time parameter (e.g., via MPI_T) that provides 4 levels:
0: do nothing 1: warn the first time a deleted function is used in a process 2: warn every time a deleted function is used in a process 3: error the first time a deleted function is used in a process
(the only difference between #1 and #2 is the annoyance factor)
The tricky part will be how to handle future function deletions -- we should pick configure / run-time parameter names that reflects removing the functions that were deleted in MPI-3 so that we leave the door open for MPI-4 deletions handled (and retired) separately.
I bring this up because it might be useful if OMPI/MPICH do similar things with regards to handling these deleted functions... We don't have to do it exactly the same, but if we're at least sorta similar, that'll be good enough.
On Mar 12, 2014, at 12:48 PM, Rajeev Thakur <[email protected]> wrote:
Added it to the ticket. https://trac.mpich.org/projects/mpich/ticket/2056
On Mar 12, 2014, at 11:38 AM, Michael Blocksome <[email protected]> wrote:
Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable?
If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision.
Michael Blocksome Parallel Environment MPI Middleware Team Lead, TCEM POWER, x86, and Blue Gene HPC Messaging [email protected]
From: Rajeev Thakur <[email protected]> To: <[email protected]>, Date: 03/11/2014 09:51 PM Subject: Re: [mpich-discuss] MPI_Address() Sent by: [email protected]
There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions.
Rajeev
On Mar 11, 2014, at 9:28 PM, Orion Poplawski <[email protected]> wrote:
MPI_Address() was removed from the MPI API in the MPI-3 specification so it should be removed from mpich's mpi.h as well. Still present in 3.1 and current repository.
- Orion
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane [email protected] Boulder, CO 80301 http://www.cora.nwra.com _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss