[mpich-discuss] MPI_Address()

[Jeff Squyres (jsquyres)]

Got any opinions on names for the configure option and run-time param option?  I'm guessing we *might* be able to use the same configure option, but I'll bet our run-time option will have a different name.  But I figured I'd ask...

(Nathan just reminded me that this also applies to all the C++ MPI:: methods, too)

How about:

1. ./configure --enable|disable-mpi3-deleted-interfaces

2. MPI_T name: mpi3_deleted_interfaces_check, which can take one of four values: none, warn_once, warn, or error




On Mar 12, 2014, at 2:06 PM, "Balaji, Pavan" <balaji at anl.gov> wrote:

> 
> Thanks, Jeff.  The four levels sounds good to me.
> 
>  — Pavan
> 
> On Mar 12, 2014, at 11:57 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> 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 <thakur at mcs.anl.gov> wrote:
>> 
>>> Added it to the ticket.
>>> https://trac.mpich.org/projects/mpich/ticket/2056
>>> 
>>> On Mar 12, 2014, at 11:38 AM, Michael Blocksome <blocksom at us.ibm.com> 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
>>>> blocksom at us.ibm.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From:        Rajeev Thakur <thakur at mcs.anl.gov> 
>>>> To:        <discuss at mpich.org>, 
>>>> Date:        03/11/2014 09:51 PM 
>>>> Subject:        Re: [mpich-discuss] MPI_Address() 
>>>> Sent by:        discuss-bounces at mpich.org 
>>>> 
>>>> 
>>>> 
>>>> 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 <orion at cora.nwra.com>
>>>> 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                  orion at cora.nwra.com
>>>>> Boulder, CO 80301              http://www.cora.nwra.com
>>>>> _______________________________________________
>>>>> discuss mailing list     discuss at mpich.org
>>>>> To manage subscription options or unsubscribe:
>>>>> https://lists.mpich.org/mailman/listinfo/discuss
>>>> 
>>>> _______________________________________________
>>>> discuss mailing list     discuss at mpich.org
>>>> To manage subscription options or unsubscribe:
>>>> https://lists.mpich.org/mailman/listinfo/discuss
>>>> 
>>>> 
>>>> _______________________________________________
>>>> discuss mailing list     discuss at mpich.org
>>>> To manage subscription options or unsubscribe:
>>>> https://lists.mpich.org/mailman/listinfo/discuss
>>> 
>>> _______________________________________________
>>> discuss mailing list     discuss at mpich.org
>>> To manage subscription options or unsubscribe:
>>> https://lists.mpich.org/mailman/listinfo/discuss
>> 
>> 
>> -- 
>> Jeff Squyres
>> jsquyres at cisco.com
>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/