Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-102-gc9c5d40
OK, revert done : commit b5aea782cec116af095a7e7a7310e9e2a018 Author: Gilles Gouaillardet List-Post: devel@lists.open-mpi.org Date: Thu Oct 16 12:24:38 2014 +0900 Revert "Fix heterogeneous support" Per the discussion at http://www.open-mpi.org/community/lists/devel/2014/10/16050.php This reverts commit c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774. Cheers, Gilles On 2014/10/16 12:13, Ralph Castain wrote: > On Oct 15, 2014, at 8:08 PM, Gilles Gouaillardet > wrote: > >> Ralph, >> >> let me quickly reply about this one : >> >> On 2014/10/16 12:00, Ralph Castain wrote: >>> I also don't understand some of the changes in this commit. For example, >>> why did you replace the OPAL_MODEX_SEND_STRING macro with essentially a >>> hard-coded replica of that macro? >> OPAL_MODEX_SEND_STRING put a key of type OPAL_BYTE_OBJECT >> >> in ompi_proc_complete_init: >>OPAL_MODEX_RECV_VALUE(ret, OPAL_DSTORE_ARCH, >> (opal_proc_t*)&proc->super, >> (void**)&ui32ptr, OPAL_UINT32); >> >> a key of type OPAL_UINT32 is expected, and an key of type >> OPAL_BYTE_OBJECT was sent >> >> i chose to "fix" the sender (e.g. send a key of type OPAL_UINT32) >> >> should i have "fixed" the receiver instead ? > Hmmm...probably the receiver, but let me take a look at it. The two should > have mirrored each other, which is why I couldn't understand the change. The > problem may be that the recv should be recv_string, but I need to look at the > two macros and see why the mirrors weren't used. > >>> Would you mind reverting this until we can better understand what is going >>> on, and decide on a path forward? >> no problem >> based on my previous comment, shall i also revert the change in >> ompi/proc/proc.c as well ? > I'd revert the commit as a whole. Let's look at the hetero issue in its > entirety and figure out how we want to handle it. > > Thanks > Ralph > >> Cheers, >> >> Gilles >> >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/10/16049.php > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/10/16050.php
Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-102-gc9c5d40
On Oct 15, 2014, at 8:08 PM, Gilles Gouaillardet wrote: > Ralph, > > let me quickly reply about this one : > > On 2014/10/16 12:00, Ralph Castain wrote: >> I also don't understand some of the changes in this commit. For example, why >> did you replace the OPAL_MODEX_SEND_STRING macro with essentially a >> hard-coded replica of that macro? > OPAL_MODEX_SEND_STRING put a key of type OPAL_BYTE_OBJECT > > in ompi_proc_complete_init: >OPAL_MODEX_RECV_VALUE(ret, OPAL_DSTORE_ARCH, > (opal_proc_t*)&proc->super, > (void**)&ui32ptr, OPAL_UINT32); > > a key of type OPAL_UINT32 is expected, and an key of type > OPAL_BYTE_OBJECT was sent > > i chose to "fix" the sender (e.g. send a key of type OPAL_UINT32) > > should i have "fixed" the receiver instead ? Hmmm...probably the receiver, but let me take a look at it. The two should have mirrored each other, which is why I couldn't understand the change. The problem may be that the recv should be recv_string, but I need to look at the two macros and see why the mirrors weren't used. >> Would you mind reverting this until we can better understand what is going >> on, and decide on a path forward? > no problem > based on my previous comment, shall i also revert the change in > ompi/proc/proc.c as well ? I'd revert the commit as a whole. Let's look at the hetero issue in its entirety and figure out how we want to handle it. Thanks Ralph > > Cheers, > > Gilles > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/10/16049.php
Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-102-gc9c5d40
Ralph, let me quickly reply about this one : On 2014/10/16 12:00, Ralph Castain wrote: > I also don't understand some of the changes in this commit. For example, why > did you replace the OPAL_MODEX_SEND_STRING macro with essentially a > hard-coded replica of that macro? OPAL_MODEX_SEND_STRING put a key of type OPAL_BYTE_OBJECT in ompi_proc_complete_init: OPAL_MODEX_RECV_VALUE(ret, OPAL_DSTORE_ARCH, (opal_proc_t*)&proc->super, (void**)&ui32ptr, OPAL_UINT32); a key of type OPAL_UINT32 is expected, and an key of type OPAL_BYTE_OBJECT was sent i chose to "fix" the sender (e.g. send a key of type OPAL_UINT32) should i have "fixed" the receiver instead ? > Would you mind reverting this until we can better understand what is going > on, and decide on a path forward? no problem based on my previous comment, shall i also revert the change in ompi/proc/proc.c as well ? Cheers, Gilles
Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-102-gc9c5d40
On Oct 15, 2014, at 6:21 PM, Gilles Gouaillardet
wrote:
> Hi Ralph,
>
> i am sorry i should have asked before pushing this to the master.
>
> the master was broken in heterogeneous mode and i took the fastest path to
> move it to a working state.
> (please note that this commit fixes ompi/proc/proc.c and this is independent
> of how opal_process_name_t vs orte_process_name_t
> are handled)
Understood - but the trunk has been broken in hetero mode for a long time. This
fixes one piece of that problem, but others remain (at least, last I heard). So
there's no rush to do this right away.
>
> the latest email i read about this was my post in the devel ML
> http://www.open-mpi.org/community/lists/devel/2014/08/15532.php
> if i remember correctly, this topic was also discussed in the weekly call
> (and i could not attend it)
Yes - and we agreed that we weren't sure of the best path forward, so we were
tabling it for now.
>
> if it is finally decided to take the second option, i am afraid it could be a
> bit trickier than what i anticipated :
> heterogeneous.v2.patch + extra steps to introduce OPAL_PROCESS_NAME dss type
> (opal_process_name_t cannot be packed/unpacked as
> opal_identifier_t/OPAL_UINT64 any more)
Could take a few more steps, but it may prove necessary. What we are having to
do right now is superimpose the jobid/vpid structure on the opal_identifier_t
anyway during startup as the RMs out there all provide a jobid and vpid. So we
have no choice but to pack it into the identifier, which means we have multiple
places where we have to overlay the opal_identifier_t.
This creates its own issues. :-/
I also don't understand some of the changes in this commit. For example, why
did you replace the OPAL_MODEX_SEND_STRING macro with essentially a hard-coded
replica of that macro?
Would you mind reverting this until we can better understand what is going on,
and decide on a path forward?
>
> i can make a proof of concept in a branch of my repository if this helps
>
> Cheers,
>
> Gilles
>
> On 2014/10/15 23:08, Ralph Castain wrote:
>> Hi Gilles
>>
>> I'm surprised this came into the trunk - last I saw, we hadn't fully decided
>> which approach we wanted to pursue. Did I miss some discussion?
>>
>> Due to some other issues, we had been leaning more towards the other
>> alternative - i.e., adding structure to the opal identifier struct. Is there
>> some reason why you chose this alternative?
>>
>>
>> Begin forwarded message:
>>
>>> From: git...@crest.iu.edu
>>> Subject: [OMPI commits] Git: open-mpi/ompi branch master updated.
>>> dev-102-gc9c5d40
>>> Date: October 15, 2014 at 3:50:43 AM PDT
>>> To: ompi-comm...@open-mpi.org
>>> Reply-To: de...@open-mpi.org
>>>
>>> This is an automated email from the git hooks/post-receive script. It was
>>> generated because a ref change was pushed to the repository containing
>>> the project "open-mpi/ompi".
>>>
>>> The branch, master has been updated
>>> via c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774 (commit)
>>> from 5c81658d58e260170c995030ac17e42a4032e2dd (commit)
>>>
>>> Those revisions listed above that are new to this repository have
>>> not appeared on any other notification email; so we list those
>>> revisions in full, below.
>>>
>>> - Log -
>>> https://github.com/open-mpi/ompi/commit/c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774
>>>
>>> commit c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774
>>> Author: Gilles Gouaillardet
>>> Date: Wed Oct 15 17:19:13 2014 +0900
>>>
>>>Fix heterogeneous support
>>>
>>>* redefine orte_process_name_t so it can be converted
>>> between host and network format as an opal_identifier_t
>>> aka uint64_t by the OPAL layer.
>>>* correctly send OPAL_DSTORE_ARCH key
>>>
>>> diff --git a/ompi/proc/proc.c b/ompi/proc/proc.c
>>> index d30182f..12b781e 100644
>>> --- a/ompi/proc/proc.c
>>> +++ b/ompi/proc/proc.c
>>> @@ -107,6 +107,7 @@ int ompi_proc_init(void)
>>> OMPI_CAST_RTE_NAME(&proc->super.proc_name)->vpid = i;
>>>
>>> if (i == OMPI_PROC_MY_NAME->vpid) {
>>> +opal_value_t kv;
>>> ompi_proc_local_proc = proc;
>>> proc->super.proc_flags = OPAL_PROC_ALL_LOCAL;
>>> proc->super.proc_hostname = strdup(ompi_process_info.nodename);
>>> @@ -115,8 +116,13 @@ int ompi_proc_init(void)
>>> opal_proc_local_set(&proc->super);
>>> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT
>>> /* add our arch to the modex */
>>> -OPAL_MODEX_SEND_STRING(ret, PMIX_SYNC_REQD, PMIX_REMOTE,
>>> OPAL_DSTORE_ARCH,
>>> - &proc->super.proc_arch, OPAL_UINT32);
>>> +OBJ_CONSTRUCT(&kv, opal_value_t);
>>> +kv.key = strdup(OPAL_DSTORE_ARCH);
>>> +kv.type = OPAL_UINT32;
>>> +kv.data.uint32 = opal_local_arch;
>>> +ret = opal_pmix.put(PMIX_REMOTE, &kv);
>>> +
Re: [OMPI devel] Fwd: [OMPI commits] Git: open-mpi/ompi branch master updated. dev-102-gc9c5d40
Hi Ralph,
i am sorry i should have asked before pushing this to the master.
the master was broken in heterogeneous mode and i took the fastest path
to move it to a working state.
(please note that this commit fixes ompi/proc/proc.c and this is
independent of how opal_process_name_t vs orte_process_name_t
are handled)
the latest email i read about this was my post in the devel ML
http://www.open-mpi.org/community/lists/devel/2014/08/15532.php
if i remember correctly, this topic was also discussed in the weekly
call (and i could not attend it)
if it is finally decided to take the second option, i am afraid it could
be a bit trickier than what i anticipated :
heterogeneous.v2.patch + extra steps to introduce OPAL_PROCESS_NAME dss type
(opal_process_name_t cannot be packed/unpacked as
opal_identifier_t/OPAL_UINT64 any more)
i can make a proof of concept in a branch of my repository if this helps
Cheers,
Gilles
On 2014/10/15 23:08, Ralph Castain wrote:
> Hi Gilles
>
> I'm surprised this came into the trunk - last I saw, we hadn't fully decided
> which approach we wanted to pursue. Did I miss some discussion?
>
> Due to some other issues, we had been leaning more towards the other
> alternative - i.e., adding structure to the opal identifier struct. Is there
> some reason why you chose this alternative?
>
>
> Begin forwarded message:
>
>> From: git...@crest.iu.edu
>> Subject: [OMPI commits] Git: open-mpi/ompi branch master updated.
>> dev-102-gc9c5d40
>> Date: October 15, 2014 at 3:50:43 AM PDT
>> To: ompi-comm...@open-mpi.org
>> Reply-To: de...@open-mpi.org
>>
>> This is an automated email from the git hooks/post-receive script. It was
>> generated because a ref change was pushed to the repository containing
>> the project "open-mpi/ompi".
>>
>> The branch, master has been updated
>> via c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774 (commit)
>> from 5c81658d58e260170c995030ac17e42a4032e2dd (commit)
>>
>> Those revisions listed above that are new to this repository have
>> not appeared on any other notification email; so we list those
>> revisions in full, below.
>>
>> - Log -
>> https://github.com/open-mpi/ompi/commit/c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774
>>
>> commit c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774
>> Author: Gilles Gouaillardet
>> Date: Wed Oct 15 17:19:13 2014 +0900
>>
>>Fix heterogeneous support
>>
>>* redefine orte_process_name_t so it can be converted
>> between host and network format as an opal_identifier_t
>> aka uint64_t by the OPAL layer.
>>* correctly send OPAL_DSTORE_ARCH key
>>
>> diff --git a/ompi/proc/proc.c b/ompi/proc/proc.c
>> index d30182f..12b781e 100644
>> --- a/ompi/proc/proc.c
>> +++ b/ompi/proc/proc.c
>> @@ -107,6 +107,7 @@ int ompi_proc_init(void)
>> OMPI_CAST_RTE_NAME(&proc->super.proc_name)->vpid = i;
>>
>> if (i == OMPI_PROC_MY_NAME->vpid) {
>> +opal_value_t kv;
>> ompi_proc_local_proc = proc;
>> proc->super.proc_flags = OPAL_PROC_ALL_LOCAL;
>> proc->super.proc_hostname = strdup(ompi_process_info.nodename);
>> @@ -115,8 +116,13 @@ int ompi_proc_init(void)
>> opal_proc_local_set(&proc->super);
>> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT
>> /* add our arch to the modex */
>> -OPAL_MODEX_SEND_STRING(ret, PMIX_SYNC_REQD, PMIX_REMOTE,
>> OPAL_DSTORE_ARCH,
>> - &proc->super.proc_arch, OPAL_UINT32);
>> +OBJ_CONSTRUCT(&kv, opal_value_t);
>> +kv.key = strdup(OPAL_DSTORE_ARCH);
>> +kv.type = OPAL_UINT32;
>> +kv.data.uint32 = opal_local_arch;
>> +ret = opal_pmix.put(PMIX_REMOTE, &kv);
>> +OBJ_DESTRUCT(&kv);
>> +
>> if (OPAL_SUCCESS != ret) {
>> return ret;
>> }
>> diff --git a/opal/util/proc.h b/opal/util/proc.h
>> index 8a52a08..db5cfbc 100644
>> --- a/opal/util/proc.h
>> +++ b/opal/util/proc.h
>> @@ -23,7 +23,7 @@
>> #include "opal/dss/dss.h"
>>
>> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT
>> -#include
>> +#include "opal/types.h"
>> #endif
>>
>> /**
>> @@ -37,22 +37,11 @@
>> typedef opal_identifier_t opal_process_name_t;
>>
>> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT && !defined(WORDS_BIGENDIAN)
>> -#define OPAL_PROCESS_NAME_NTOH(guid) opal_process_name_ntoh_intr(&(guid))
>> -static inline __opal_attribute_always_inline__ void
>> -opal_process_name_ntoh_intr(opal_process_name_t *name)
>> -{
>> -uint32_t * w = (uint32_t *)name;
>> -w[0] = ntohl(w[0]);
>> -w[1] = ntohl(w[1]);
>> -}
>> -#define OPAL_PROCESS_NAME_HTON(guid) opal_process_name_hton_intr(&(guid))
>> -static inline __opal_attribute_always_inline__ void
>> -opal_process_name_hton_intr(opal_process_name_t *name)
>> -{
>> -uint32_t * w = (uint32_t *)name;
>> -w[0] = htonl(w[0]);
>> -w[1] = htonl(w[1]);
>> -}
>> +#define OPAL_PROCESS_NAME_NTOH(guid) \
>> +g
[OMPI devel] Slurm direct-launch is broken on trunk
When attempting to launch via srun: [bend001:03708] pmix: get all keys for proc 327680 in KVS 5.0 [bend001:03708] GETTING KEY 327680-key0 [bend001:03708] Read data AcG1peC5obmFtZQAwMwAwMDA4AGJlbmQwMDEAcG1peC5scmFuawAwZAAwMDAycG1peC5ucmFuawAwZAAwMA - [bend001:03708] UNSUPPORTED TYPE 0 [bend001:03708] OPAL ERROR: Error in file pmix_s1.c at line 458 [bend001:03709] [[5,0],2] pmix:s1 barrier complete [bend001:03709] pmix: get all keys for proc 327680 in KVS 5.0 [bend001:03709] GETTING KEY 327680-key0 [bend001:03709] Read data AcG1peC5obmFtZQAwMwAwMDA4AGJlbmQwMDEAcG1peC5scmFuawAwZAAwMDAycG1peC5ucmFuawAwZAAwMA - [bend001:03709] UNSUPPORTED TYPE 0 [bend001:03709] OPAL ERROR: Error in file pmix_s1.c at line 458 [bend001:03708] [[5,0],1] pmix:s1 called get for key pmix.hname [bend001:03708] pmix: get all keys for proc 327680 in KVS 5.0 [bend001:03708] GETTING KEY 327680-key0 [bend001:03708] Read data AcG1peC5obmFtZQAwMwAwMDA4AGJlbmQwMDEAcG1peC5scmFuawAwZAAwMDAycG1peC5ucmFuawAwZAAwMA - [bend001:03708] UNSUPPORTED TYPE 0 [bend001:03708] [[5,0],1] pmix:s1 got key pmix.hname Looks like someone broke the common code for decoding keys. Could you please fix it? Ralph
[OMPI devel] Fwd: [OMPI commits] Git: open-mpi/ompi branch master updated. dev-102-gc9c5d40
Hi Gilles
I'm surprised this came into the trunk - last I saw, we hadn't fully decided
which approach we wanted to pursue. Did I miss some discussion?
Due to some other issues, we had been leaning more towards the other
alternative - i.e., adding structure to the opal identifier struct. Is there
some reason why you chose this alternative?
Begin forwarded message:
> From: git...@crest.iu.edu
> Subject: [OMPI commits] Git: open-mpi/ompi branch master updated.
> dev-102-gc9c5d40
> Date: October 15, 2014 at 3:50:43 AM PDT
> To: ompi-comm...@open-mpi.org
> Reply-To: de...@open-mpi.org
>
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi".
>
> The branch, master has been updated
> via c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774 (commit)
> from 5c81658d58e260170c995030ac17e42a4032e2dd (commit)
>
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
>
> - Log -
> https://github.com/open-mpi/ompi/commit/c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774
>
> commit c9c5d4011bf6ea1ade1a5bd9b6a77f02157dc774
> Author: Gilles Gouaillardet
> Date: Wed Oct 15 17:19:13 2014 +0900
>
>Fix heterogeneous support
>
>* redefine orte_process_name_t so it can be converted
> between host and network format as an opal_identifier_t
> aka uint64_t by the OPAL layer.
>* correctly send OPAL_DSTORE_ARCH key
>
> diff --git a/ompi/proc/proc.c b/ompi/proc/proc.c
> index d30182f..12b781e 100644
> --- a/ompi/proc/proc.c
> +++ b/ompi/proc/proc.c
> @@ -107,6 +107,7 @@ int ompi_proc_init(void)
> OMPI_CAST_RTE_NAME(&proc->super.proc_name)->vpid = i;
>
> if (i == OMPI_PROC_MY_NAME->vpid) {
> +opal_value_t kv;
> ompi_proc_local_proc = proc;
> proc->super.proc_flags = OPAL_PROC_ALL_LOCAL;
> proc->super.proc_hostname = strdup(ompi_process_info.nodename);
> @@ -115,8 +116,13 @@ int ompi_proc_init(void)
> opal_proc_local_set(&proc->super);
> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT
> /* add our arch to the modex */
> -OPAL_MODEX_SEND_STRING(ret, PMIX_SYNC_REQD, PMIX_REMOTE,
> OPAL_DSTORE_ARCH,
> - &proc->super.proc_arch, OPAL_UINT32);
> +OBJ_CONSTRUCT(&kv, opal_value_t);
> +kv.key = strdup(OPAL_DSTORE_ARCH);
> +kv.type = OPAL_UINT32;
> +kv.data.uint32 = opal_local_arch;
> +ret = opal_pmix.put(PMIX_REMOTE, &kv);
> +OBJ_DESTRUCT(&kv);
> +
> if (OPAL_SUCCESS != ret) {
> return ret;
> }
> diff --git a/opal/util/proc.h b/opal/util/proc.h
> index 8a52a08..db5cfbc 100644
> --- a/opal/util/proc.h
> +++ b/opal/util/proc.h
> @@ -23,7 +23,7 @@
> #include "opal/dss/dss.h"
>
> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT
> -#include
> +#include "opal/types.h"
> #endif
>
> /**
> @@ -37,22 +37,11 @@
> typedef opal_identifier_t opal_process_name_t;
>
> #if OPAL_ENABLE_HETEROGENEOUS_SUPPORT && !defined(WORDS_BIGENDIAN)
> -#define OPAL_PROCESS_NAME_NTOH(guid) opal_process_name_ntoh_intr(&(guid))
> -static inline __opal_attribute_always_inline__ void
> -opal_process_name_ntoh_intr(opal_process_name_t *name)
> -{
> -uint32_t * w = (uint32_t *)name;
> -w[0] = ntohl(w[0]);
> -w[1] = ntohl(w[1]);
> -}
> -#define OPAL_PROCESS_NAME_HTON(guid) opal_process_name_hton_intr(&(guid))
> -static inline __opal_attribute_always_inline__ void
> -opal_process_name_hton_intr(opal_process_name_t *name)
> -{
> -uint32_t * w = (uint32_t *)name;
> -w[0] = htonl(w[0]);
> -w[1] = htonl(w[1]);
> -}
> +#define OPAL_PROCESS_NAME_NTOH(guid) \
> +guid = ntoh64(guid)
> +
> +#define OPAL_PROCESS_NAME_HTON(guid) \
> +guid = hton64(guid)
> #else
> #define OPAL_PROCESS_NAME_NTOH(guid)
> #define OPAL_PROCESS_NAME_HTON(guid)
> diff --git a/orte/include/orte/types.h b/orte/include/orte/types.h
> index c9ae320..f14b527 100644
> --- a/orte/include/orte/types.h
> +++ b/orte/include/orte/types.h
> @@ -10,6 +10,8 @@
> * Copyright (c) 2004-2005 The Regents of the University of California.
> * All rights reserved.
> * Copyright (c) 2014 Intel, Inc. All rights reserved.
> + * Copyright (c) 2014 Research Organization for Information Science
> + * and Technology (RIST). All rights reserved.
> * $COPYRIGHT$
> *
> * Additional copyrights may follow
> @@ -83,17 +85,17 @@ typedef uint32_t orte_vpid_t;
> #define ORTE_VPID_MAX UINT32_MAX-2
> #define ORTE_VPID_MIN 0
>
> -#define ORTE_PROCESS_NAME_HTON(n) \
> -do {\
> -n.jobid = htonl(n.jobid); \
> -n.vpid = htonl(n.vpid); \
>
[OMPI devel] Missing f08 binding for Win_allocate
Hello, The f08 binding for Win_allocate is missing in master and 1.8 series. I fixed the problem based on master. The attached patch also works for 1.8.3. I found some documentation in the wiki but I am not sure if this is intended for small fixes like this as well. How shall I proceed to get this into master after the svn->git transition? * Open a bug first * fork + pull request or * email patch from git format-patch to devel list? Best regards Christoph Niethammer -- Christoph Niethammer High Performance Computing Center Stuttgart (HLRS) Nobelstrasse 19 70569 Stuttgart Tel: ++49(0)711-685-87203 email: nietham...@hlrs.de http://www.hlrs.de/people/niethammerFrom 7b81fe5584ddc675aca7a09a7f59b5658254318f Mon Sep 17 00:00:00 2001 From: Christoph Niethammer Date: Wed, 15 Oct 2014 15:56:56 +0200 Subject: [PATCH] Add missing Fortran binding for Win_allocate. --- ompi/mpi/fortran/mpif-h/Makefile.am| 1 + ompi/mpi/fortran/mpif-h/profile/Makefile.am| 1 + ompi/mpi/fortran/mpif-h/profile/defines.h | 2 + ompi/mpi/fortran/mpif-h/prototypes_mpi.h | 2 + ompi/mpi/fortran/mpif-h/win_allocate_f.c | 137 + ompi/mpi/fortran/use-mpi-f08/Makefile.am | 2 + .../fortran/use-mpi-f08/mpi-f-interfaces-bind.h| 13 ++ .../mpi/fortran/use-mpi-f08/mpi-f08-interfaces.F90 | 17 ++- .../fortran/use-mpi-f08/pmpi-f-interfaces-bind.h | 13 ++ .../use-mpi-f08/profile/pwin_allocate_f08.F90 | 28 + ompi/mpi/fortran/use-mpi-f08/win_allocate_f08.F90 | 28 + .../mpi-ignore-tkr-interfaces.h.in | 26 .../use-mpi-tkr/mpi-f90-cptr-interfaces.F90| 29 + 13 files changed, 298 insertions(+), 1 deletion(-) create mode 100644 ompi/mpi/fortran/mpif-h/win_allocate_f.c create mode 100644 ompi/mpi/fortran/use-mpi-f08/profile/pwin_allocate_f08.F90 create mode 100644 ompi/mpi/fortran/use-mpi-f08/win_allocate_f08.F90 diff --git a/ompi/mpi/fortran/mpif-h/Makefile.am b/ompi/mpi/fortran/mpif-h/Makefile.am index b727329..f254975 100644 --- a/ompi/mpi/fortran/mpif-h/Makefile.am +++ b/ompi/mpi/fortran/mpif-h/Makefile.am @@ -386,6 +386,7 @@ libmpi_mpifh_la_SOURCES += \ rput_f.c \ compare_and_swap_f.c \ fetch_and_op_f.c \ +win_allocate_f.c \ win_allocate_shared_f.c \ win_call_errhandler_f.c \ win_complete_f.c \ diff --git a/ompi/mpi/fortran/mpif-h/profile/Makefile.am b/ompi/mpi/fortran/mpif-h/profile/Makefile.am index 793c45c..66712df 100644 --- a/ompi/mpi/fortran/mpif-h/profile/Makefile.am +++ b/ompi/mpi/fortran/mpif-h/profile/Makefile.am @@ -314,6 +314,7 @@ linked_files = \ prput_f.c \ pcompare_and_swap_f.c \ pfetch_and_op_f.c \ +pwin_allocate_f.c \ pwin_allocate_shared_f.c \ pwin_call_errhandler_f.c \ pwin_complete_f.c \ diff --git a/ompi/mpi/fortran/mpif-h/profile/defines.h b/ompi/mpi/fortran/mpif-h/profile/defines.h index 43b21b7..94fd9e4 100644 --- a/ompi/mpi/fortran/mpif-h/profile/defines.h +++ b/ompi/mpi/fortran/mpif-h/profile/defines.h @@ -344,6 +344,8 @@ #define ompi_waitany_f pompi_waitany_f #define ompi_wait_f pompi_wait_f #define ompi_waitsome_f pompi_waitsome_f +#define ompi_win_allocate_f pompi_win_allocate_f +#define ompi_win_allocate_cptr_f pompi_win_allocate_cptr_f #define ompi_win_allocate_shared_f pompi_win_allocate_shared_f #define ompi_win_allocate_shared_cptr_f pompi_win_allocate_shared_cptr_f #define ompi_win_call_errhandler_f pompi_win_call_errhandler_f diff --git a/ompi/mpi/fortran/mpif-h/prototypes_mpi.h b/ompi/mpi/fortran/mpif-h/prototypes_mpi.h index f3115c3..b8ac7da 100644 --- a/ompi/mpi/fortran/mpif-h/prototypes_mpi.h +++ b/ompi/mpi/fortran/mpif-h/prototypes_mpi.h @@ -401,6 +401,8 @@ PN2(void, MPI_Waitall, mpi_waitall, MPI_WAITALL, (MPI_Fint *count, MPI_Fint *arr PN2(void, MPI_Waitany, mpi_waitany, MPI_WAITANY, (MPI_Fint *count, MPI_Fint *array_of_requests, MPI_Fint *index, MPI_Fint *status, MPI_Fint *ierr)); PN2(void, MPI_Wait, mpi_wait, MPI_WAIT, (MPI_Fint *request, MPI_Fint *status, MPI_Fint *ierr)); PN2(void, MPI_Waitsome, mpi_waitsome, MPI_WAITSOME, (MPI_Fint *incount, MPI_Fint *array_of_requests, MPI_Fint *outcount, MPI_Fint *array_of_indices, MPI_Fint *array_of_statuses, MPI_Fint *ierr)); +PN2(void, MPI_Win_allocate, mpi_win_allocate, MPI_WIN_ALLOCATE, (MPI_Aint *size, MPI_Fint *disp_unit, MPI_Fint *info, MPI_Fint *comm, char *baseptr, MPI_Fint *win, MPI_Fint *ierr)); +PN2(void, MPI_Win_allocate_cptr, mpi_win_allocate_cptr, MPI_WIN_ALLOCATE_CPTR, (MPI_Aint *size, MPI_Fint *disp_unit, MPI_Fint *info, MPI_Fint *comm, char *baseptr, MPI_Fint *win, MPI_Fint *ierr)); PN2(void, MPI_Win_allocate_shared, mpi_win_allocate_shared, MPI_WIN_ALLOCATE_SHARED, (MPI_Aint *size, MPI_Fint *disp_unit, MPI_Fint *info, MPI_Fint *comm, char *baseptr, MPI_Fint *win, MPI_Fint *ierr)); PN2(void, MPI_Win_allocate_shared_cptr, mpi_win_allocate_shared_cptr, MPI
