- devel - mailman3.cels.anl.gov

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8
by Balaji, Pavan 27 Feb '14

27 Feb '14

On Feb 27, 2014, at 1:32 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: >> # If the program linked OK, make sure there were no warnings >> - if test "$prog_links" = "yes" -a "`cat pac_test.log`" = "" ; then >> + if test "$prog_links" = "yes" -a "`diff pac_test1.log pac_test2.log`" = "" ; then >> AC_DEFINE([HAVE_MACRO_VA_ARGS],[1],[Define if C99-style variable argument list macro functionality]) >> AC_MSG_RESULT([yes]) >> + elif "`diff pac_test1.log pac_test2.log`" = "" ; then > > This is bad shell code. You probably want "elif test" instead. Gah. Yes. My sh —> bash symlink didn’t catch it. Thanks. Should probabyl also do test -z rather than compare with the empty string. — Pavan

1 0

Fwd: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8
by Dave Goodell (dgoodell) 27 Feb '14

27 Feb '14

I saw this fly by and a bug caught the corner of my eye (see inline) Begin forwarded message: > From: Service Account <noreply(a)mpich.org> > Subject: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8 > Date: February 27, 2014 11:27:24 AM PST > To: <all-commits(a)mpich.org>, <commits(a)mpich.org> > Reply-To: <commits(a)mpich.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 "MPICH primary repository". > > The branch, master has been updated > via de80ec8704071f3b9c810509fb8acee345865902 (commit) > from 956047a2696bdfb51d66f56d0b226df8d40ebd80 (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 ----------------------------------------------------------------- > http://git.mpich.org/mpich.git/commitdiff/de80ec8704071f3b9c810509fb8acee34… > > commit de80ec8704071f3b9c810509fb8acee345865902 > Author: Pavan Balaji <balaji(a)mcs.anl.gov> > Date: Wed Feb 26 11:49:46 2014 -0600 > > Better checks for VA_ARGS. > > We were disabling VA_ARGS whenever the compiler throws warnings. > However, in some cases, the compiler is throwing warnings in general > (because of bad user-specified flags) and not specifically because of > VA_ARGS. See discussion on the discuss(a)mpich.org mailing list: > http://lists.mpich.org/pipermail/discuss/2014-February/002246.html > > This patch works around this issue by checking the difference in the > warning flags with and without VA_ARGS. > > Fixes #2047. > > Signed-off-by: Huiwei Lu <huiweilu(a)mcs.anl.gov> > > diff --git a/confdb/aclocal_cc.m4 b/confdb/aclocal_cc.m4 > index f73aa4c..2612e94 100644 > --- a/confdb/aclocal_cc.m4 > +++ b/confdb/aclocal_cc.m4 > @@ -1644,22 +1644,35 @@ AC_DEFUN([PAC_C_MACRO_VA_ARGS],[ > AC_MSG_CHECKING([for variable argument list macro functionality]) > > # check if the program links correctly > - rm -f pac_test.log > - PAC_LINK_IFELSE_LOG([pac_test.log],[AC_LANG_PROGRAM([ > + rm -f pac_test1.log pac_test2.log > + > + PAC_LINK_IFELSE_LOG([pac_test1.log],[AC_LANG_PROGRAM([ > #include <stdio.h> > #define conftest_va_arg_macro(...) printf(__VA_ARGS__) > ], > [conftest_va_arg_macro("a test %d", 3);])], > prog_links=yes,prog_links=no) > > + PAC_LINK_IFELSE_LOG([pac_test2.log],[AC_LANG_PROGRAM([ > + #include <stdio.h> > + #define conftest_va_arg_macro printf > + ], > + [conftest_va_arg_macro("a test %d", 3);])]) > + > # If the program linked OK, make sure there were no warnings > - if test "$prog_links" = "yes" -a "`cat pac_test.log`" = "" ; then > + if test "$prog_links" = "yes" -a "`diff pac_test1.log pac_test2.log`" = "" ; then > AC_DEFINE([HAVE_MACRO_VA_ARGS],[1],[Define if C99-style variable argument list macro functionality]) > AC_MSG_RESULT([yes]) > + elif "`diff pac_test1.log pac_test2.log`" = "" ; then This is bad shell code. You probably want "elif test" instead. -Dave > + AC_MSG_RESULT([no, compiler generates warnings]) > + echo "With VA_ARGS:" > + cat pac_test1.log > + echo "Without VA_ARGS:" > + cat pac_test2.log > else > AC_MSG_RESULT([no]) > fi > - rm -f pac_test.log > + rm -f pac_test1.log pac_test2.log > ])dnl > > # Will AC_DEFINE([HAVE_BUILTIN_EXPECT]) if the compiler supports __builtin_expect. > > ----------------------------------------------------------------------- > > Summary of changes: > confdb/aclocal_cc.m4 | 21 +++++++++++++++++---- > 1 files changed, 17 insertions(+), 4 deletions(-) > > > hooks/post-receive > -- > MPICH primary repository

1 0

Re: [mpich-devel] Incorrect semantics in test/mpi/rma/reqops.c
by Jeff Hammond 25 Feb '14

25 Feb '14

Hi Nathan, I'd strongly encourage you to run ARMCI-MPI's test suite when you're done, if for no other reason than I will do so the day you announce OpenMPI supports MPI-3 RMA and blast you with bug reports if anything fails :-D See http://wiki.mpich.org/armci-mpi/index.php/Main_Page for details. Note that you need to explicitly checkout the mpi3rma branch to touch those features. Feel free to annoy the heck out of me if there's anything you don't like about ARMCI-MPI. I certainly deserve intense scrutiny if I'm going to threaten you with bug reports :-D In the event that you're doing MPI-3 RMA in OpenMPI sans datatype support (i.e. the same as OpenMPI's MPI-2 RMA), ARMCI-MPI can handle this. The relevant env vars to disable the datatype code path are documented in an obviously-named file (probably README, but I am too lazy to confirm it with the repo). Finally, if you really want to watch the world burn, try running NWChem with ARMCI-MPI using your MPI-3 RMA implementation. http://wiki.mpich.org/armci-mpi/index.php/NWChem has build instructions for Intel SDK (contact me for other cases if necessary). Feel free to harass me at the Forum if necessary. Best, Jeff On Tue, Feb 25, 2014 at 5:03 PM, Nathan Hjelm <hjelmn(a)lanl.gov> wrote: > Hello, I am finishing MPI-3 RMA support in Open MPI and I am using the > MPICH test suite to test the new functionality before release. I think > I found a bug in one of your tests. The reqops test does the following > in one of its loops: > > for (i = 0; i < ITER; i++) { > MPI_Request req; > int val = -1, exp = -1; > > /* Processes form a ring. Process 0 starts first, then passes a token > * to the right. Each process, in turn, performs third-party > * communication via process 0's window. */ > if (rank > 0) { > MPI_Recv(NULL, 0, MPI_BYTE, rank-1, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > } > > MPI_Rget(&val, 1, MPI_INT, 0, 0, 1, MPI_INT, window, &req); > assert(req != MPI_REQUEST_NULL); > MPI_Wait(&req, MPI_STATUS_IGNORE); > > MPI_Rput(&rank, 1, MPI_INT, 0, 0, 1, MPI_INT, window, &req); > assert(req != MPI_REQUEST_NULL); > MPI_Wait(&req, MPI_STATUS_IGNORE); > > exp = (rank + nproc-1) % nproc; > > if (val != exp) { > printf("%d - Got %d, expected %d\n", rank, val, exp); > errors++; > } > > if (rank < nproc-1) { > MPI_Send(NULL, 0, MPI_BYTE, rank+1, 0, MPI_COMM_WORLD); > } > > MPI_Barrier(MPI_COMM_WORLD); > } > > > The problem is that no call is being made to ensure the RMA operation is > complete at the target as per MPI-3 p432 13-17: > > "The completion of an MPI_RPUT operation (i.e., after the corresponding > test or wait) indicates that the sender is now free to update the > locations in the origin buffer. It does not indicate that the data is > available at the target window. If remote completion is required, > MPI_WIN_FLUSH, MPI_WIN_FLUSH_ALL, MPI_WIN_UNLOCK, or MPI_WIN_UNLOCK_ALL > can be used." > > > Not ensuring remote completion may cause processes further down the ring > to read a value written by a process other than the previous process in > the ring. > > The fix is to add MPI_Win_flush (0, window) before the MPI_Send. I can > confirm that this fixes the issue with Open MPI. Please see the attached > patch. > > > -Nathan Hjelm > HPC-5, LANL > -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-devel] Incorrect semantics in test/mpi/rma/reqops.c
by Jim Dinan 25 Feb '14

25 Feb '14

Yep, that's a bug. Patch looks like the right fix to me. ~Jim. On Tue, Feb 25, 2014 at 6:03 PM, Nathan Hjelm <hjelmn(a)lanl.gov> wrote: > Hello, I am finishing MPI-3 RMA support in Open MPI and I am using the > MPICH test suite to test the new functionality before release. I think > I found a bug in one of your tests. The reqops test does the following > in one of its loops: > > for (i = 0; i < ITER; i++) { > MPI_Request req; > int val = -1, exp = -1; > > /* Processes form a ring. Process 0 starts first, then passes a > token > * to the right. Each process, in turn, performs third-party > * communication via process 0's window. */ > if (rank > 0) { > MPI_Recv(NULL, 0, MPI_BYTE, rank-1, 0, MPI_COMM_WORLD, > MPI_STATUS_IGNORE); > } > > MPI_Rget(&val, 1, MPI_INT, 0, 0, 1, MPI_INT, window, &req); > assert(req != MPI_REQUEST_NULL); > MPI_Wait(&req, MPI_STATUS_IGNORE); > > MPI_Rput(&rank, 1, MPI_INT, 0, 0, 1, MPI_INT, window, &req); > assert(req != MPI_REQUEST_NULL); > MPI_Wait(&req, MPI_STATUS_IGNORE); > > exp = (rank + nproc-1) % nproc; > > if (val != exp) { > printf("%d - Got %d, expected %d\n", rank, val, exp); > errors++; > } > > if (rank < nproc-1) { > MPI_Send(NULL, 0, MPI_BYTE, rank+1, 0, MPI_COMM_WORLD); > } > > MPI_Barrier(MPI_COMM_WORLD); > } > > > The problem is that no call is being made to ensure the RMA operation is > complete at the target as per MPI-3 p432 13-17: > > "The completion of an MPI_RPUT operation (i.e., after the corresponding > test or wait) indicates that the sender is now free to update the > locations in the origin buffer. It does not indicate that the data is > available at the target window. If remote completion is required, > MPI_WIN_FLUSH, MPI_WIN_FLUSH_ALL, MPI_WIN_UNLOCK, or MPI_WIN_UNLOCK_ALL > can be used." > > > Not ensuring remote completion may cause processes further down the ring > to read a value written by a process other than the previous process in > the ring. > > The fix is to add MPI_Win_flush (0, window) before the MPI_Send. I can > confirm that this fixes the issue with Open MPI. Please see the attached > patch. > > > -Nathan Hjelm > HPC-5, LANL > >

1 0

Incorrect semantics in test/mpi/rma/reqops.c
by Nathan Hjelm 25 Feb '14

25 Feb '14

Hello, I am finishing MPI-3 RMA support in Open MPI and I am using the MPICH test suite to test the new functionality before release. I think I found a bug in one of your tests. The reqops test does the following in one of its loops: for (i = 0; i < ITER; i++) { MPI_Request req; int val = -1, exp = -1; /* Processes form a ring. Process 0 starts first, then passes a token * to the right. Each process, in turn, performs third-party * communication via process 0's window. */ if (rank > 0) { MPI_Recv(NULL, 0, MPI_BYTE, rank-1, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); } MPI_Rget(&val, 1, MPI_INT, 0, 0, 1, MPI_INT, window, &req); assert(req != MPI_REQUEST_NULL); MPI_Wait(&req, MPI_STATUS_IGNORE); MPI_Rput(&rank, 1, MPI_INT, 0, 0, 1, MPI_INT, window, &req); assert(req != MPI_REQUEST_NULL); MPI_Wait(&req, MPI_STATUS_IGNORE); exp = (rank + nproc-1) % nproc; if (val != exp) { printf("%d - Got %d, expected %d\n", rank, val, exp); errors++; } if (rank < nproc-1) { MPI_Send(NULL, 0, MPI_BYTE, rank+1, 0, MPI_COMM_WORLD); } MPI_Barrier(MPI_COMM_WORLD); } The problem is that no call is being made to ensure the RMA operation is complete at the target as per MPI-3 p432 13-17: "The completion of an MPI_RPUT operation (i.e., after the corresponding test or wait) indicates that the sender is now free to update the locations in the origin buffer. It does not indicate that the data is available at the target window. If remote completion is required, MPI_WIN_FLUSH, MPI_WIN_FLUSH_ALL, MPI_WIN_UNLOCK, or MPI_WIN_UNLOCK_ALL can be used." Not ensuring remote completion may cause processes further down the ring to read a value written by a process other than the previous process in the ring. The fix is to add MPI_Win_flush (0, window) before the MPI_Send. I can confirm that this fixes the issue with Open MPI. Please see the attached patch. -Nathan Hjelm HPC-5, LANL

1 0

Re: [mpich-devel] Dynamic process management test case issue?
by Rajeev Thakur 22 Feb '14

22 Feb '14

Thanks for the bug report. Pavan has fixed it in the repo. Rajeev On Feb 21, 2014, at 11:15 AM, "Archer, Charles J" <charles.j.archer(a)intel.com> wrote: > Hi. > > The test case test/mpi/spawn/concurrent_spawns.c mixes MPI_Comm_free with MPI_Comm_disconnect (lines 115/122) from different ranks on the same inter-communicator. > > Both MPI_Comm_free and MPI_Comm_disconnect are defined as collective (although possibly implemented with reference counting or non-collective behavior...most MPI's don't synchronize). As far as I know there is no precedent for mixing different collective calls across ranks in a communicator, so symmetric calls to disconnect or free should be made....but don't mix them. > > I understand for free/disconnect, "collective" does not necessarily mean synchronizing, but the specification is clear that comm disconnect/free should be considered collective. See the test cmfree.c as an example of a test case that relies on collective, but not synchronizing behavior of free(). There is language in the spec indicating that disconnect "has the same action" as free (page 400), but I don't think it implies that you can mix the calls. Additionally, what does it mean to disconnect one side of the connection? > > I can't find any solid evidence that this test case is legal. At first glance, the example on page 396 of the spec seems to indicate that mixing is allowed. However mixing cannot happen; the example is confusing. > > If mixing free/disconnect was intentional, I think we probably need some clarification of the MPI spec with regards to this....unless I'm missing something entirely. > > Here is a patch that fixes this test case, please weigh in if you have some insight. > > diff --git a/test/mpi/spawn/concurrent_spawns.c b/test/mpi/spawn/concurrent_spawns.c > index e44f53a..df82b13 100644 > --- a/test/mpi/spawn/concurrent_spawns.c > +++ b/test/mpi/spawn/concurrent_spawns.c > @@ -119,7 +119,7 @@ int main(int argc, char *argv[]) > if (parentcomm != MPI_COMM_NULL) > { > MPI_Send(&errs, 1, MPI_INT, 0, 0, parentcomm); > - MPI_Comm_free( &parentcomm ); > + MPI_Comm_disconnect( &parentcomm ); > } > else { > /* Note that the MTest_Finalize get errs only over COMM_WORLD */

1 0

Re: [mpich-devel] remove armci?
by Balaji, Pavan 21 Feb '14

21 Feb '14

Oh, yes. We were supposed to do that. I’ll create a ticket for it. — Pavan On 2/20/14, 2:27 PM, "Jeff Hammond" <jeff.science(a)gmail.com> wrote: >I thought armci was going to be removed from MPICH because it now >lives at git.mpich.org/armci-mpi.git/. > >Seems like a waste of CO2 to ship these files around the internet >unnecessarily at this point. > >Best, > >Jeff > >-- >Jeff Hammond >jeff.science(a)gmail.com

1 0

Dynamic process management test case issue?
by Archer, Charles J 21 Feb '14

21 Feb '14

Hi. The test case test/mpi/spawn/concurrent_spawns.c mixes MPI_Comm_free with MPI_Comm_disconnect (lines 115/122) from different ranks on the same inter-communicator. Both MPI_Comm_free and MPI_Comm_disconnect are defined as collective (although possibly implemented with reference counting or non-collective behavior...most MPI's don't synchronize). As far as I know there is no precedent for mixing different collective calls across ranks in a communicator, so symmetric calls to disconnect or free should be made....but don't mix them. I understand for free/disconnect, "collective" does not necessarily mean synchronizing, but the specification is clear that comm disconnect/free should be considered collective. See the test cmfree.c as an example of a test case that relies on collective, but not synchronizing behavior of free(). There is language in the spec indicating that disconnect "has the same action" as free (page 400), but I don't think it implies that you can mix the calls. Additionally, what does it mean to disconnect one side of the connection? I can't find any solid evidence that this test case is legal. At first glance, the example on page 396 of the spec seems to indicate that mixing is allowed. However mixing cannot happen; the example is confusing. If mixing free/disconnect was intentional, I think we probably need some clarification of the MPI spec with regards to this....unless I'm missing something entirely. Here is a patch that fixes this test case, please weigh in if you have some insight. diff --git a/test/mpi/spawn/concurrent_spawns.c b/test/mpi/spawn/concurrent_spawns.c index e44f53a..df82b13 100644 --- a/test/mpi/spawn/concurrent_spawns.c +++ b/test/mpi/spawn/concurrent_spawns.c @@ -119,7 +119,7 @@ int main(int argc, char *argv[]) if (parentcomm != MPI_COMM_NULL) { MPI_Send(&errs, 1, MPI_INT, 0, 0, parentcomm); - MPI_Comm_free( &parentcomm ); + MPI_Comm_disconnect( &parentcomm ); } else { /* Note that the MTest_Finalize get errs only over COMM_WORLD */

1 0

remove armci?
by Jeff Hammond 20 Feb '14

20 Feb '14

I thought armci was going to be removed from MPICH because it now lives at git.mpich.org/armci-mpi.git/. Seems like a waste of CO2 to ship these files around the internet unnecessarily at this point. Best, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

MPI::Op::Reduce_local() missing const
by Jeff Squyres (jsquyres) 05 Feb '14

05 Feb '14

<drive by bug report> I was doing a comparison with MPICH 3.0.4 tonight to try to track down a bug in OMPI and noticed that MPICH's MPI::Op::Reduce_local() binding is missing the const declaration. </drive by bug report> -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0