MPI_*_get_info/set_info() #2941

markalle · 2017-02-08T21:38:09Z

This is built off of Dave Solt's earlier pull request #1308.

Roughly what Dave did is:

change ompi_{communicator,win,file}_t to have opal_infosubscriber_t as their .super class
change ompi_info_t to have opal_info_t as its .super class
transition a lot of the ompi_info_* calls to opal_info_*

I fixed memory leaks, compiler warnings, and changed the semantics to support the current interpretation of the MPI standard.

The main functions are
opal_infosubscribe_infosubscribe() : register a callback fn for a particular key
opal_infosubscribe_change_info() : used at MPI_*_set_info() time
opal_info_dup_mpistandard() : extracts the k/v as defined for MPI_*_get_info()

jjhursey · 2017-02-08T21:39:55Z

Ref PR #1308

jjhursey · 2017-02-08T22:10:54Z

bot:ibm:pgi:retest

ibm-ompi · 2017-02-08T22:40:16Z

Build Failed with PGI compiler! Please review the log, and get in touch if you have questions.

Gist: https://gist.github.com/0f51d7bc06a4ab54bd6a7adeed9f5ded

jjhursey · 2017-02-09T03:19:31Z

I originally thought that the PGI CI failure was a local system issue. However, it seems legit, as best I can tell.

  CC       src/io_romio314_module.lo
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-W-0093-Type cast required for this conversion of constant (src/io_romio314_module.c: 108)
PGC-S-0073-Too many initializers for mca_io_romio314_module (src/io_romio314_module.c: 108)
PGC/power Linux 16.10-0: compilation completed with severe errors

jjhursey · 2017-02-09T03:26:15Z

Yeah it looks like romio needs to be updated in this PR too. I'm not sure why the PGI compiler is the sensitive one here, but it's a good catch.

The CI configures with:

./configure --without-x CC=pgcc CXX=pgc++ FC=pgfortran

@markalle If you need access to the PGI compiler just ping me and I'll let you know where they are on the ppc64le dev machines.

jsquyres

I only took a very cursory glance at this PR.

If it wasn't done so, I'm guessing @dsolt's original commit needs to be rebased to the top of master. That might prevent some "you need to upgrade ROMIO" issues (i.e., the ROMIO at the top master is working fine with the PGI compiler; there's no reason this PR should be regressing ROMIO).

Also, the signed-off-by checker failed. All commits need to be signed off.

jsquyres · 2017-02-09T11:54:29Z

AUTHORS

@@ -81,6 +80,8 @@ Dave Goodell, Cisco
  dgoodell@cisco.com
 David Daniel, Los Alamos National Laboratory
  ddd@lanl.gov
+David Solt, IBM
+  dsolt@us.ibm.com


Note that AUTHORS is generated automatically these days.

I reverted it anyway, so dave's checkin now adds a line, and my checkin removes it so the two commits together should be a no-op on AUTHORS

jsquyres · 2017-02-09T11:54:41Z

ompi/communicator/comm.c

@@ -22,6 +22,7 @@
 *                         and Technology (RIST). All rights reserved.
 * Copyright (c) 2014-2015 Intel, Inc. All rights reserved.
 * Copyright (c) 2015      Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 IBM Corp.  All rights reserved.


Shouldn't these copyright updates be 2017 now?

jsquyres · 2017-02-09T11:56:37Z

ompi/mca/io/romio314/src/io_romio314_component.c

+// I don't think there's any advantage to most of the code being switched
+// to opal_info_t, which is causing the unnecessary extra complexity here:
+    ompi_info_t *ompi_info;
+    ompi_info = OBJ_NEW(ompi_info_t);


Need to check for NULL here.

Thanks, I made a change for checking that NULL

jsquyres · 2017-02-09T11:57:20Z

ompi/mca/io/romio314/src/io_romio314_component.c

+// I'd be open to reverting most of it back to ompi_info_t and using
+// opal_info_* calls on the opal_info_t that's inside the ompi_info_t.
+// I don't think there's any advantage to most of the code being switched
+// to opal_info_t, which is causing the unnecessary extra complexity here:


Seems like this comment should be addressed...? (a similar comment is repeated several times)

I guess a decision needs made for what is the predominant design. Dave has ompi_info_t as the larger class that contains an opal_info_t plus a tiny bit extra (like a fortran int id). All the top level MPI calls that use info come in with an ompi_info_t*.

Dave's overall design is to migrate toward the code from that point down being largely opal_info_t. I don't really disagree, although it does end up with an awful lot of
some_function(mpiinfo) becoming some_function(&mpiinfo->super) // to get the opal_info_t
and equivalently, if you just want to pass MPI_INFO_NULL to some routine, but it wants an opal_info_t*, you have to give it &MPI_INFO_NULL->super.

And there are a tiny number of places where the lower level code calls back into MPI, and thus needs the larger ompi_info_t when all it has is an opal_info_t, thus having the extra code you quoted that's making another copy of the info that isn't logically necessary. That bothers me, but it's only 3 places... so I guess I'm leaning toward reverting my comment, and sticking with the design of having the lower level code predominantly using opal_info_t.

ibm-ompi · 2017-02-10T23:35:53Z

Build Failed with PGI compiler! Please review the log, and get in touch if you have questions.

Gist: https://gist.github.com/56af0cc8bee2c10cc19913afd2737780

gpaulsen · 2017-02-17T21:47:45Z

PGI compiler issues is fixes, Jeff's review comments have been updated.

We think this is ready to merge to master. Can we merge it in, so that @hjelmn can begin using this? If the MPI Forum changes their minds on open questions about this, we can address those in a separate PR.

jjhursey · 2017-02-17T21:50:53Z

bot:ibm:retest

gpaulsen · 2017-02-21T18:27:25Z

@jsquyres can you please re-review?

jjhursey · 2017-03-06T22:26:11Z

@markalle It looks like this branch needs to be rebased again. Can you do that so @jsquyres can review again?

ibm-ompi · 2017-04-11T06:57:06Z

The IBM CI (PGI Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/7a1f378bca3c4e57a1bf40f857338b69

gpaulsen · 2017-04-25T15:50:45Z

We'd like to come to a conclusion on this discussion and close this out.
It needs to be rebased (again). If MPI_Forum changes it's current thinking, it should be easy to change.

jsquyres · 2017-04-26T00:07:27Z

bot:lanl:retest

jsquyres · 2017-04-26T00:07:51Z

bot:ibm:retest

ibm-ompi · 2017-04-26T00:26:25Z

The IBM CI (PGI Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/b318cdde19cffc6796c960dce0b5196c

jsquyres · 2017-04-26T00:42:28Z

@gpaulsen @markalle IBM PGI compile testing is failing. Can you guys have a look?

gpaulsen · 2017-04-26T01:12:57Z

Absolutely. The current theory is that after a rebase it might get resolved. But time will tell.

jsquyres · 2017-04-26T02:34:00Z

@gpaulsen Ok. Then let's do the rebase before the next review (otherwise, it'll just have to be reviewed again, right?).

jsquyres

At first glance, I get a bunch of compiler warnings:

  CC       info_subscriber.lo
info_subscriber.c: In function 'opal_infosubscribe_testregister':
info_subscriber.c:175:11: warning: unused variable 'next_key' [-Wunused-variable]
     char *next_key;
           ^
info_subscriber.c:174:11: warning: unused variable 'node' [-Wunused-variable]
     void *node = NULL;
           ^
info_subscriber.c:173:12: warning: unused variable 'key_size' [-Wunused-variable]
     size_t key_size;
            ^
info_subscriber.c:172:9: warning: unused variable 'err' [-Wunused-variable]
     int err;
         ^
info_subscriber.c: In function 'opal_infosubscribe_change_info':
info_subscriber.c:300:18: warning: unused variable 'list' [-Wunused-variable]
     opal_list_t *list = NULL;
                  ^
info_subscriber.c:299:32: warning: unused variable 'item' [-Wunused-variable]
     opal_callback_list_item_t *item;
                                ^
info_subscriber.c:298:24: warning: unused variable 'table' [-Wunused-variable]
     opal_hash_table_t *table = &object->s_subscriber_table;
                        ^
info_subscriber.c:297:11: warning: unused variable 'next_key' [-Wunused-variable]
     char *next_key;
           ^
info_subscriber.c:296:11: warning: unused variable 'node' [-Wunused-variable]
     void *node = NULL;
           ^
info_subscriber.c:293:9: warning: unused variable 'flag' [-Wunused-variable]
     int flag;
         ^
info_subscriber.c:292:12: warning: unused variable 'key_size' [-Wunused-variable]
     size_t key_size;
            ^

And also some new common symbols (which should be avoided):

$ make install-exec-hook
WARNING!  Common symbols found:
                   info.o: 0000000000000100 C ompi_mpi_info_env
                   info.o: 0000000000000100 C ompi_mpi_info_null

Also, the 30_get test failed in ompi-tests/info:

Running test: mpirun -np 4 ./30_get
[**ERROR**]: MPI_COMM_WORLD rank 2, file 30_get.c:68:
Info_get obtained value "valu", expected up to 5 characters of "value1"
[**ERROR**]: MPI_COMM_WORLD rank 0, file 30_get.c:68:
Info_get obtained value "valu", expected up to 5 characters of "value1"
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 2 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[**ERROR**]: MPI_COMM_WORLD rank 1, file 30_get.c:68:
Info_get obtained value "valu", expected up to 5 characters of "value1"
[**ERROR**]: MPI_COMM_WORLD rank 3, file 30_get.c:68:
Info_get obtained value "valu", expected up to 5 characters of "value1"
[savbu-usnic-a:10885] 3 more processes have sent help message help-mpi-api.txt / mpi-abort
Exit status: 1
FAIL 30_get (exit status: 1)

jsquyres · 2017-05-10T15:30:14Z

Also, if the 2nd commit on this PR is just fixes for the first commit, might as well squash them down into a single commit.

ompi_communicator_t, ompi_win_t, ompi_file_t all have a super class of type opal_infosubscriber_t instead of a base/super type of opal_object_t (in previous code comm used c_base, but file used super). It may be a bit bold to say that being a subscriber of MPI_Info is the foundational piece that ties these three things together, but if you object, then I would prefer to turn infosubscriber into a more general name that encompasses other common features rather than create a different super class. The key here is that we want to be able to pass comm, win and file objects as if they were opal_infosubscriber_t, so that one routine can heandle all 3 types of objects being passed to it. MPI_INFO_NULL is still an ompi_predefined_info_t type since an MPI_Info is part of ompi but the internal details of the underlying information concept is part of opal. An ompi_info_t type still exists for exposure to the user, but it is simply a wrapper for the opal object. Routines such as ompi_info_dup, etc have all been moved to opal_info_dup and related to the opal directory. Fortran to C translation tables are only used for MPI_Info that is exposed to the application and are therefore part of the ompi_info_t and not the opal_info_t The data structure changes are primarily in the following files: communicator/communicator.h ompi/info/info.h ompi/win/win.h ompi/file/file.h The following new files were created: opal/util/info.h opal/util/info.c opal/util/info_subscriber.h opal/util/info_subscriber.c This infosubscriber concept is that communicators, files and windows can have subscribers that subscribe to any changes in the info associated with the comm/file/window. When xxx_set_info is called, the new info is presented to each subscriber who can modify the info in any way they want. The new value is presented to the next subscriber and so on until all subscribers have had a chance to modify the value. Therefore, the order of subscribers can make a difference but we hope that there is generally only one subscriber that cares or modifies any given key/value pair. The final info is then stored and returned by a call to xxx_get_info. The new model can be seen in the following files: ompi/mpi/c/comm_get_info.c ompi/mpi/c/comm_set_info.c ompi/mpi/c/file_get_info.c ompi/mpi/c/file_set_info.c ompi/mpi/c/win_get_info.c ompi/mpi/c/win_set_info.c The current subscribers where changed as follows: mca/io/ompio/io_ompio_file_open.c mca/io/ompio/io_ompio_module.c mca/osc/rmda/osc_rdma_component.c (This one actually subscribes to "no_locks") mca/osc/sm/osc_sm_component.c (This one actually subscribes to "blocking_fence" and "alloc_shared_contig") Signed-off-by: Mark Allen <markalle@us.ibm.com> Conflicts: AUTHORS ompi/communicator/comm.c ompi/debuggers/ompi_mpihandles_dll.c ompi/file/file.c ompi/file/file.h ompi/info/info.c ompi/mca/io/ompio/io_ompio.h ompi/mca/io/ompio/io_ompio_file_open.c ompi/mca/io/ompio/io_ompio_file_set_view.c ompi/mca/osc/pt2pt/osc_pt2pt.h ompi/mca/sharedfp/addproc/sharedfp_addproc.h ompi/mca/sharedfp/addproc/sharedfp_addproc_file_open.c ompi/mca/topo/treematch/topo_treematch_dist_graph_create.c ompi/mpi/c/lookup_name.c ompi/mpi/c/publish_name.c ompi/mpi/c/unpublish_name.c opal/mca/mpool/base/mpool_base_alloc.c opal/util/Makefile.am

markalle · 2017-05-12T19:26:05Z

Okay, I removed the unused variables.

I don't think the two commons are really additions:

    info.o: 0000000000000100 C ompi_mpi_info_env
    info.o: 0000000000000100 C ompi_mpi_info_null

they were previously
ompi_predefined_info_t ompi_mpi_info_env = {{{{0}}}};
and now are just
ompi_predefined_info_t ompi_mpi_info_env;
so maybe that changed the storage area for them.

And they're used from mpi.h as
#define MPI_INFO_ENV OMPI_PREDEFINED_GLOBAL(MPI_Info, ompi_mpi_info_env)
for example, so they're meant to be globals in some form.

On the length I agree, I introduced that bug and I can't see why I made that change, I reverted it.

markalle · 2017-05-12T19:27:09Z

Oh, for the squash, yeah I'm okay with that. It's just since Dave did the initial work it had been convenient for me to be able to distinguish what he did from what I changed.

ibm-ompi · 2017-05-12T19:34:54Z

The IBM CI (GNU Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/fe5ed39c3b59af6a683826aa06d86eda

rhc54 · 2017-05-12T19:36:18Z

you can squash selectively - so you can squash yours down to one, and his down to another

ibm-ompi · 2017-05-12T19:38:40Z

The IBM CI (XL Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/ab258c38d7e8e3fdf7a9f13d9ac24c66

ibm-ompi · 2017-05-12T19:39:36Z

The IBM CI (PGI Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/0ec3785261b70f70f047bbf895c89c2b

markalle · 2017-05-15T15:59:16Z

The last rebase brought in a need for interlib.c to #include "mpi.h" so it could see MPI_THREAD_SINGLE. I don't know what changed in the chain of includes that used to let it see that, but that's what made the previous CI test fail, so I added that change and re-pushed.

markalle · 2017-05-16T19:07:36Z

I've been keeping it squashed to two commits: one from dave, one from me. I think @jsquyres was proposing squashing dave's and mine together.

Having them separated was useful for example when Jeff noted that test 30_get.c was failing and I could see whether that bug was my fault or Dave's (it was mine). But it's not critical, so I can squash to one if you want.

rhc54 · 2017-05-16T19:08:34Z

nah - tell @jsquyres to get a life and leave it as two 😄

jsquyres

I think there's only a little left:

The copyrights are still a bit weird. You can do whatever you want there, but IMHO, it's a little weird to introduce new code in May of 2017 with a copyright of "2016" or "2016-17". I know that the code has sat around since 2016, but my point is that the first commit that actually gets into master will be in 2017.
There was at least one copyright addition on a file with no other changes.
The only real issue left is the common symbols:

$ make install-exec-hook
WARNING!  Common symbols found:
                   info.o: 0000000000000100 C ompi_mpi_info_env
                   info.o: 0000000000000100 C ompi_mpi_info_null

Those should be fixed.

jsquyres · 2017-05-16T19:18:41Z

ompi/communicator/communicator.h

@@ -20,7 +20,7 @@
 * Copyright (c) 2014-2015 Intel, Inc.  All rights reserved.
 * Copyright (c) 2015      Research Organization for Information Science
 *                         and Technology (RIST). All rights reserved.
- * Copyright (c) 2017      IBM Corporation.  All rights reserved.
+ * Copyright (c) 2016-2017 IBM Corporation. All rights reserved.


This retroactive copyright addition seems odd...?

jsquyres · 2017-05-16T20:01:00Z

ompi/dpm/dpm.c

@@ -18,6 +18,7 @@
 * Copyright (c) 2013-2016 Intel, Inc.  All rights reserved.
 * Copyright (c) 2014-2017 Research Organization for Information Science
 *                         and Technology (RIST). All rights reserved.
+ * Copyright (c) 2016-2017 IBM Corporation. All rights reserved.


Any particular reason for this copyright addition?

jsquyres · 2017-05-16T20:02:01Z

ompi/file/file.h

@@ -15,6 +15,7 @@
 * Copyright (c) 2015      Research Organization for Information Science
 *                         and Technology (RIST). All rights reserved.
 * Copyright (c) 2016      University of Houston. All rights reserved.
+ * Copyright (c) 2016 IBM Corp.  All rights reserved.


jsquyres · 2017-05-16T20:04:49Z

ompi/mca/fs/lustre/fs_lustre_file_delete.c

@@ -10,6 +10,7 @@
 * Copyright (c) 2004-2005 The Regents of the University of California.
 *                         All rights reserved.
 * Copyright (c) 2008-2011 University of Houston. All rights reserved.
+ * Copyright (c) 2016 IBM Corp.  All rights reserved.


jsquyres · 2017-05-16T20:05:22Z

ompi/mca/fs/lustre/fs_lustre_file_open.c

@@ -12,6 +12,7 @@
 * Copyright (c) 2008-2015 University of Houston. All rights reserved.
 * Copyright (c) 2015      Research Organization for Information Science
 *                         and Technology (RIST). All rights reserved.
+ * Copyright (c) 2016 IBM Corp.  All rights reserved.


markalle · 2017-05-16T22:11:48Z

@jsquyres
Did you see my earlier explanation of those commons?

They were previously
ompi_predefined_info_t ompi_mpi_info_env = {{{{0}}}};
and now are just
ompi_predefined_info_t ompi_mpi_info_env;
so maybe that changed the storage area for them.

And they're used from mpi.h as
#define MPI_INFO_ENV OMPI_PREDEFINED_GLOBAL(MPI_Info, ompi_mpi_info_env)
for example, so they're meant to be globals in some form.

markalle · 2017-05-16T22:16:49Z

I'm guessing the copyright additions that say 2016 started back then, like you said. And the unmodified files with copyright additions had some change we later reverted. I guess removing all 2016 additions wouldn't be that hard.

rhc54 · 2017-05-16T22:24:14Z

I don't know - I think that's getting into a little gray area. True, those changes weren't merged until 2017, but that isn't when the copyright applies. The copyright attests to when those changes were written, not when they became public. So I think @jsquyres is incorrect here and those copyrights should stay the way they are.

That's why your IP lawyers always insist you enter dates into your "notebooks" - the legal origination of the idea is the date in the notebook, not the date of publication.

jsquyres · 2017-05-16T22:25:53Z

@markalle Yes, I saw your explanations. But one way or another, we should not be introducing new common symbols. 😄 I guess I'm asking: shouldn't these new info symbols be able to be like other mpi.h symbols (e.g., ompi_mpi_comm_world)?

markalle · 2017-05-16T23:15:56Z

I pushed again, with another pass through the copyrights, removing about a dozen files where the copyright was the only change, and changing a bunch of 2016 to 2017

rhc54 · 2017-05-16T23:17:59Z

As I said, I honestly don't believe the changes from 2016 to 2017 are legally correct - but I honestly also don't think it's important as the copyright notices don't really mean anything in this context.

The expected sequence of events for processing info during object creation is that if there's an incoming info arg, it is opal_info_dup()ed into the obj at obj->s_info first. Then interested components register callbacks for keys they want to know about using opal_infosubscribe_infosubscribe(). Inside info_subscribe_subscribe() the specified callback() is called with whatever matching k/v is in the object's info, or with the default. The return string from the callback goes into the new k/v stored in info, and the input k/v is saved as __IN_<key>/<val>. It's saved the same way whether the input came from info or whether it was a default. A null return from the callback indicates an ignored key/val, and no k/v is stored for it, but an __IN_<key>/<val> is still kept so we still have access to the original. At MPI_*_set_info() time, opal_infosubscribe_change_info() is used. That function calls the registered callbacks for each item in the provided info. If the callback returns non-null, the info is updated with that k/v, or if the callback returns null, that key is deleted from info. An __IN_<key>/<val> is saved either way, and overwrites any previously saved value. When MPI_*_get_info() is called, opal_info_dup_mpistandard() is used, which allows relatively easy changes in interpretation of the standard, by looking at both the <key>/<val> and __IN_<key>/<val> in info. Right now it does 1. includes system extras, eg k/v defaults not expliclty set by the user 2. omits ignored keys 3. shows input values, not callback modifications, eg not the internal values Currently the callbacks are doing things like return some_condition ? "true" : "false" that is, returning static strings that are not to be freed. If the return strings start becoming more dynamic in the future I don't see how unallocated strings could support that, so I'd propose a change for the future that the callback()s registered with info_subscribe_subscribe() do a strdup on their return, and we change the callers of callback() to free the strings it returns (there are only two callers). Rough outline of the smaller changes spread over the less central files: comm.c initialize comm->super.s_info to NULL copy into comm->super.s_info in comm creation calls that provide info OBJ_RELEASE comm->super.s_info at free time comm_init.c initialize comm->super.s_info to NULL file.c copy into file->super.s_info if file creation provides info OBJ_RELEASE file->super.s_info at free time win.c copy into win->super.s_info if win creation provides info OBJ_RELEASE win->super.s_info at free time comm_get_info.c file_get_info.c win_get_info.c change_info() if there's no info attached (shouldn't happen if callbacks are registered) copy the info for the user The other category of change is generally addressing compiler warnings where ompi_info_t and opal_info_t were being used a little too interchangably. An ompi_info_t* contains an opal_info_t*, at &(ompi_info->super) Also this commit updates the copyrights. Signed-off-by: Mark Allen <markalle@us.ibm.com>

markalle · 2017-05-17T05:19:22Z

Well darn, I didn't see Ralph's copyright comments until I had already made the change. But fortunately I still had a list of every file my previous script had run on, so for every file that used to contain 2016 I switched it back to 2016-2017.

And I finally removed the commons. I figured there must have been some reason why Dave had removed the {{{{0}}}} initializer that used to be there, but I can't fathom any reason not to initialize it so I'm guessing it was just the inconvenience of the syntax of figuring out how many braces it should have.

jsquyres

I confirm that the common symbols are gone.

Thanks for you patience, @markalle

gpaulsen · 2017-05-19T20:16:46Z

:bot:help

markalle · 2017-05-19T20:17:52Z

:retest:

hjelmn · 2017-05-22T13:25:07Z

:bot:retest:

jsquyres requested changes Feb 9, 2017

View reviewed changes

markalle force-pushed the pr/mpi-info-update2 branch from 2b5f6c3 to 336f389 Compare February 10, 2017 23:00

This was referenced Feb 14, 2017

Implement MPI_Comm_set_info() and MPI_Comm_get_info() #398

Closed

MPI_Info update (2nd / corrected PR) #1308

Closed

markalle force-pushed the pr/mpi-info-update2 branch 3 times, most recently from ffaf595 to f9f4779 Compare February 15, 2017 18:07

gpaulsen mentioned this pull request Mar 7, 2017

v3.0.0 feature whitelist #3107

Closed

6 tasks

markalle force-pushed the pr/mpi-info-update2 branch 3 times, most recently from 7a4e195 to dd9c108 Compare March 8, 2017 20:23

markalle force-pushed the pr/mpi-info-update2 branch from dd9c108 to 2c95427 Compare April 28, 2017 18:45

jsquyres requested changes May 10, 2017

View reviewed changes

markalle force-pushed the pr/mpi-info-update2 branch from c0fba40 to 7eb4a3e Compare May 12, 2017 19:23

markalle force-pushed the pr/mpi-info-update2 branch from 7eb4a3e to 9b11854 Compare May 15, 2017 14:58

jsquyres requested changes May 16, 2017

View reviewed changes

markalle force-pushed the pr/mpi-info-update2 branch from 9b11854 to c209196 Compare May 16, 2017 23:15

markalle force-pushed the pr/mpi-info-update2 branch from c209196 to 482d84b Compare May 17, 2017 05:13

jsquyres approved these changes May 17, 2017

View reviewed changes

gpaulsen merged commit 50f9287 into open-mpi:master May 22, 2017

MPI_*_get_info/set_info() #2941

MPI_*_get_info/set_info() #2941

Conversation

markalle commented Feb 8, 2017 • edited by jsquyres Loading

jjhursey commented Feb 8, 2017

jjhursey commented Feb 8, 2017

ibm-ompi commented Feb 8, 2017

jjhursey commented Feb 9, 2017

jjhursey commented Feb 9, 2017

jsquyres left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ibm-ompi commented Feb 10, 2017

gpaulsen commented Feb 17, 2017

jjhursey commented Feb 17, 2017

gpaulsen commented Feb 21, 2017

jjhursey commented Mar 6, 2017

ibm-ompi commented Apr 11, 2017

gpaulsen commented Apr 25, 2017

jsquyres commented Apr 26, 2017

jsquyres commented Apr 26, 2017

ibm-ompi commented Apr 26, 2017

jsquyres commented Apr 26, 2017

gpaulsen commented Apr 26, 2017

jsquyres commented Apr 26, 2017

jsquyres left a comment

Choose a reason for hiding this comment

jsquyres commented May 10, 2017

markalle commented May 12, 2017

markalle commented May 12, 2017

ibm-ompi commented May 12, 2017

rhc54 commented May 12, 2017

ibm-ompi commented May 12, 2017

ibm-ompi commented May 12, 2017

markalle commented May 15, 2017

markalle commented May 16, 2017

rhc54 commented May 16, 2017

jsquyres left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markalle commented May 16, 2017

markalle commented May 16, 2017

rhc54 commented May 16, 2017

jsquyres commented May 16, 2017

markalle commented May 16, 2017

rhc54 commented May 16, 2017

markalle commented May 17, 2017

jsquyres left a comment

Choose a reason for hiding this comment

gpaulsen commented May 19, 2017

markalle commented May 19, 2017

hjelmn commented May 22, 2017

markalle commented Feb 8, 2017 •

edited by jsquyres

Loading