[OMPI devel] RFC: Merge PMIx branch to trunk
WHAT:Merge the PMIx branch into the devel repo, creating a new OPAL “lmix” framework to abstract PMI support for all RTEs. Replace the ORTE daemon-level collectives with a new PMIx server and update the ORTE grpcomm framework to support server-to-server collectives WHY: We’ve had problems dealing with variations in PMI implementations, and need to extend the existing PMI definitions to meet exascale requirements. WHEN: Mon, Aug 25 WHERE: https://github.com/rhc54/ompi-svn-mirror.git Several community members have been working on a refactoring of the current PMI support within OMPI. Although the APIs are common, Slurm and Cray implement a different range of capabilities, and package them differently. For example, Cray provides an integrated PMI-1/2 library, while Slurm separates the two and requires the user to specify the one to be used at runtime. In addition, several bugs in the Slurm implementations have caused problems requiring extra coding. All this has led to a slew of #if’s in the PMI code and bugs when the corner-case logic for one implementation accidentally traps the other. Extending this support to other implementations would have increased this complexity to an unacceptable level. Accordingly, we have: * created a new OPAL “pmix” framework to abstract the PMI support, with separate components for Cray, Slurm PMI-1, and Slurm PMI-2 implementations. * Replaced the current ORTE grpcomm daemon-based collective operation with an integrated PMIx server, and updated the grpcomm APIs to provide more flexible, multi-algorithm support for collective operations. At this time, only the xcast and allgather operations are supported. * Replaced the current global collective id with a signature based on the names of the participating procs. The allows an unlimited number of collectives to be executed by any group of processes, subject to the requirement that only one collective can be active at a time for a unique combination of procs. Note that a proc can be involved in any number of simultaneous collectives - it is the specific combination of procs that is subject to the constraint * removed the prior OMPI/OPAL modex code * added new macros for executing modex send/recv to simplify use of the new APIs. The send macros allow the caller to specify whether or not the BTL supports async modex operations - if so, then the non-blocking “fence” operation is used, if the active PMIx component supports it. Otherwise, the default is a full blocking modex exchange as we currently perform. * retained the current flag that directs us to use a blocking fence operation, but only to retrieve data upon demand
Re: [OMPI devel] RFC: add opal/threads/spinlock.h
SHARED is only supported when the pthread library does support spinlock, while in all other case it falls back into using atomic locks. Providing support only for a small fraction of environments without reporting errors or providing any alternative on other systems is difficult to accept. I think I prefer your suggestion to integrate this with the atomic locks and provide a single mechanism to handle them. Regarding this do you think there will be a need to separate the spinlocks and the atomic locks? George. On Thu, Aug 14, 2014 at 11:40 AM, Dave Goodell (dgoodell) < dgood...@cisco.com> wrote: > WHAT: Add a new "opal/threads/spinlock.h" header to OPAL that will > typically use the OS spinlock primitives if present. > > WHY: opal_mutex_t is too slow for some use cases and opal_atomic_lock_t is > inefficiently implemented for most architectures > > WHEN: timeout is after next week's engineering call on Tuesday, 2014-08-19 > > > As discussed at the June developer meeting, I propose this patch to add > spinlocks to OPAL. There are at least a half dozen reasonable ways to > implement spinlocks; which one is best will vary from platform to platform. > In general, the OS spinlock implementations are well tested and efficient. > We should usually be relying on those implementations instead of rolling > our own. > > > My primary criticism of this patch is that it muddies the waters a bit > with opal_atomic_lock_t. An alternative approach would be to spend some > time working on improving the opal_atomic_lock_t implementation, but I have > two concerns with this approach: > > 1) It's very difficult for me to measure the potential performance impact > of opal_atomic_lock_t modifications on all of the various platforms that we > currently run on. Adding this new implementation allows component > maintainers to decide if and when to convert to using the new facility. > > 2) There's a reasonable chance that I'll make a mistake. Writing tests > for this stuff helps to catch the really basic errors, but it doesn't help > as much with the really subtle mistakes. > > -Dave > > > ___ > 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/08/15652.php >
Re: [OMPI devel] [1.8.2rc4] OSHMEM fortran bindings with bad compilers
Josh, The specific compilers that caused the most problems are the older PGI compilers (any before 13.x). In this case the user has the option to update their compiler to 13.10 or newer. There are also issues with IBM's xlf. For the IBM compiler I have never found a version that builds/links the MPI f08 bindings, and now also find no version that can link the OSHMEM fortran bindings. -Paul -Paul On Thu, Aug 14, 2014 at 11:30 AM, Joshua Ladd wrote: > We will update the README accordingly. Thank you, Paul. > > Josh > > > On Thu, Aug 14, 2014 at 10:00 AM, Jeff Squyres (jsquyres) < > jsquy...@cisco.com> wrote: > >> Good points. >> >> Mellanox -- can you update per Paul's suggestions? >> >> >> On Aug 13, 2014, at 8:26 PM, Paul Hargrove wrote: >> >> > The following is NOT a bug report. >> > This is just an observation that may deserve some text in the README. >> > >> > I've reported issues in the past with some Fortran compilers (mostly >> older XLC and PGI) which either cannot build the "use mpi_f08" module, or >> cannot correctly link to it (and sometimes this fails only if configured >> with --enable-debug). >> > >> > Testing the OSHMEM Fortran bindings (enabled by default on Linux) I >> have found several compilers which fail to link the examples >> (hello_oshmemfh and ring_oshmemfh). I reported one specific instance (with >> xlc-11/xlf-13) back in February: >> http://www.open-mpi.org/community/lists/devel/2014/02/14057.php >> > >> > So far I have these failures only on platforms where the Fortran >> compiler is *known* to be broken for the MPI f90 and/or f08 bindings. >> Specifically, all the failing platforms are ones on which either: >> > + Configure determines (without my help) that FC cannot build the F90 >> and/or F08 modules. >> > OR >> > + I must pass --enable-mpi-fortran=usempi or --enable-mpi-fortran=mpifh >> for cases configure cannot detect. >> > >> > So, I do *not* believe there is anything wrong with the OSHMEM code, >> which is why I started this post with "The following is NOT a bug report". >> However, I have two recommendations to make: >> > >> > 1) Documentation >> > >> > The README says just: >> > >> > --disable-oshmem-fortran >> > Disable building only the Fortran OSHMEM bindings. >> > >> > So, I recommend adding a sentence there referencing the "Compiler >> Notes" section of the README which has details on some known bad Fortran >> compilers. >> > >> > 2) Configure: >> > >> > As I noted above, at least some of the failures are on platforms where >> configure has determined it cannot build the f08 MPI bindings. So, maybe >> there is something that could be done at configure time to disqualify some >> Fortran compilers from building the OSHMEM fotran bindings, too. >> > >> > -Paul >> > >> > -- >> > Paul H. Hargrove phhargr...@lbl.gov >> > Future Technologies Group >> > Computer and Data Sciences Department Tel: +1-510-495-2352 >> > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >> > ___ >> > 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/08/15643.php >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> 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/08/15650.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/08/15653.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Re: [OMPI devel] [1.8.2rc4] OSHMEM fortran bindings with bad compilers
We will update the README accordingly. Thank you, Paul. Josh On Thu, Aug 14, 2014 at 10:00 AM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrote: > Good points. > > Mellanox -- can you update per Paul's suggestions? > > > On Aug 13, 2014, at 8:26 PM, Paul Hargrove wrote: > > > The following is NOT a bug report. > > This is just an observation that may deserve some text in the README. > > > > I've reported issues in the past with some Fortran compilers (mostly > older XLC and PGI) which either cannot build the "use mpi_f08" module, or > cannot correctly link to it (and sometimes this fails only if configured > with --enable-debug). > > > > Testing the OSHMEM Fortran bindings (enabled by default on Linux) I have > found several compilers which fail to link the examples (hello_oshmemfh and > ring_oshmemfh). I reported one specific instance (with xlc-11/xlf-13) back > in February: > http://www.open-mpi.org/community/lists/devel/2014/02/14057.php > > > > So far I have these failures only on platforms where the Fortran > compiler is *known* to be broken for the MPI f90 and/or f08 bindings. > Specifically, all the failing platforms are ones on which either: > > + Configure determines (without my help) that FC cannot build the F90 > and/or F08 modules. > > OR > > + I must pass --enable-mpi-fortran=usempi or --enable-mpi-fortran=mpifh > for cases configure cannot detect. > > > > So, I do *not* believe there is anything wrong with the OSHMEM code, > which is why I started this post with "The following is NOT a bug report". > However, I have two recommendations to make: > > > > 1) Documentation > > > > The README says just: > > > > --disable-oshmem-fortran > > Disable building only the Fortran OSHMEM bindings. > > > > So, I recommend adding a sentence there referencing the "Compiler Notes" > section of the README which has details on some known bad Fortran compilers. > > > > 2) Configure: > > > > As I noted above, at least some of the failures are on platforms where > configure has determined it cannot build the f08 MPI bindings. So, maybe > there is something that could be done at configure time to disqualify some > Fortran compilers from building the OSHMEM fotran bindings, too. > > > > -Paul > > > > -- > > Paul H. Hargrove phhargr...@lbl.gov > > Future Technologies Group > > Computer and Data Sciences Department Tel: +1-510-495-2352 > > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > ___ > > 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/08/15643.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/08/15650.php >
[OMPI devel] RFC: add opal/threads/spinlock.h
WHAT: Add a new "opal/threads/spinlock.h" header to OPAL that will typically use the OS spinlock primitives if present. WHY: opal_mutex_t is too slow for some use cases and opal_atomic_lock_t is inefficiently implemented for most architectures WHEN: timeout is after next week's engineering call on Tuesday, 2014-08-19 As discussed at the June developer meeting, I propose this patch to add spinlocks to OPAL. There are at least a half dozen reasonable ways to implement spinlocks; which one is best will vary from platform to platform. In general, the OS spinlock implementations are well tested and efficient. We should usually be relying on those implementations instead of rolling our own. My primary criticism of this patch is that it muddies the waters a bit with opal_atomic_lock_t. An alternative approach would be to spend some time working on improving the opal_atomic_lock_t implementation, but I have two concerns with this approach: 1) It's very difficult for me to measure the potential performance impact of opal_atomic_lock_t modifications on all of the various platforms that we currently run on. Adding this new implementation allows component maintainers to decide if and when to convert to using the new facility. 2) There's a reasonable chance that I'll make a mistake. Writing tests for this stuff helps to catch the really basic errors, but it doesn't help as much with the really subtle mistakes. -Dave 0001-add-opal-threads-spinlock.h.patch Description: 0001-add-opal-threads-spinlock.h.patch
Re: [OMPI devel] 1.8.4rc4 is out
Woot -- thank you! On Aug 14, 2014, at 1:19 AM, Ralph Castain wrote: > Fantastic - thanks Paul!!! > > > > On Wed, Aug 13, 2014 at 9:18 PM, Paul Hargrove wrote: > I have completed testing the majority of the platforms I have access to. > The only issue that is not already known to exist in earlier releases was the > missing osx/atomic.h, for which Ralph promptly merged George's fix. > > If I include the re-tested osx-atomics (which passes w/ 1.8.2rc5r32531), I > have success on 75 distinct configurations which include x86, x86-64, > sparc-v8+, sparc64-v9, ppc32 and ppc64 ABIs with various releases of Linux, > Mac OS X, Solaris, FreeBSD, NetBSD and OpenBSD, with all sorts of compilers, > and static linking (w/o romio :-)) on at least one configuration for each OS. > > I will have results on ia64, ARMv5, ARMv7 and 3 MIPS ABIs in the next day or > two. > > Looks good to me. > -Paul > > > On Wed, Aug 13, 2014 at 1:37 PM, Jeff Squyres (jsquyres) > wrote: > Please test! Ralph would like to release after the teleconf next Tuesday: > > http://www.open-mpi.org/software/ompi/v1.8/ > > Changes since last rc: > > - Fix cascading/over-quoting in some cases with the rsh/ssh-based > launcher. Thanks to multiple users for raising the issue. > - Properly add support for gfortran 4.9 ignore TKR pragma (it was > erroneously only partially added in v1.7.5). Thanks to Marcus > Daniels for raising the issue. > - Update/improve help messages in the usnic BTL. > - Resolve a race condition in MPI_Abort. > - Fix obscure cases where static linking from wrapper compilers would > fail. > - Clarify the configure --help message about when OpenSHMEM is > enabled/disabled by default. Thanks to Paul Hargrove for the > suggestion. > - Align pages properly where relevant. Thanks to Paul Hargrove for > identifying the issue. > - Various compiler warning and minor fixes for OpenBSD, FreeBSD, and > Solaris/SPARC. Thanks to Paul Hargrove for the patches. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/08/15640.php > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > ___ > 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/08/15647.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/08/15649.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] [1.8.2rc4] OSHMEM fortran bindings with bad compilers
Good points. Mellanox -- can you update per Paul's suggestions? On Aug 13, 2014, at 8:26 PM, Paul Hargrove wrote: > The following is NOT a bug report. > This is just an observation that may deserve some text in the README. > > I've reported issues in the past with some Fortran compilers (mostly older > XLC and PGI) which either cannot build the "use mpi_f08" module, or cannot > correctly link to it (and sometimes this fails only if configured with > --enable-debug). > > Testing the OSHMEM Fortran bindings (enabled by default on Linux) I have > found several compilers which fail to link the examples (hello_oshmemfh and > ring_oshmemfh). I reported one specific instance (with xlc-11/xlf-13) back > in February: http://www.open-mpi.org/community/lists/devel/2014/02/14057.php > > So far I have these failures only on platforms where the Fortran compiler is > *known* to be broken for the MPI f90 and/or f08 bindings. Specifically, all > the failing platforms are ones on which either: > + Configure determines (without my help) that FC cannot build the F90 and/or > F08 modules. > OR > + I must pass --enable-mpi-fortran=usempi or --enable-mpi-fortran=mpifh for > cases configure cannot detect. > > So, I do *not* believe there is anything wrong with the OSHMEM code, which is > why I started this post with "The following is NOT a bug report". However, I > have two recommendations to make: > > 1) Documentation > > The README says just: > > --disable-oshmem-fortran > Disable building only the Fortran OSHMEM bindings. > > So, I recommend adding a sentence there referencing the "Compiler Notes" > section of the README which has details on some known bad Fortran compilers. > > 2) Configure: > > As I noted above, at least some of the failures are on platforms where > configure has determined it cannot build the f08 MPI bindings. So, maybe > there is something that could be done at configure time to disqualify some > Fortran compilers from building the OSHMEM fotran bindings, too. > > -Paul > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > ___ > 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/08/15643.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] 1.8.4rc4 is out
Fantastic - thanks Paul!!! On Wed, Aug 13, 2014 at 9:18 PM, Paul Hargrove wrote: > I have completed testing the majority of the platforms I have access to. > The only issue that is not already known to exist in earlier releases was > the missing osx/atomic.h, for which Ralph promptly merged George's fix. > > If I include the re-tested osx-atomics (which passes w/ 1.8.2rc5r32531), I > have success on 75 distinct configurations which include x86, x86-64, > sparc-v8+, sparc64-v9, ppc32 and ppc64 ABIs with various releases of Linux, > Mac OS X, Solaris, FreeBSD, NetBSD and OpenBSD, with all sorts of > compilers, and static linking (w/o romio :-)) on at least one configuration > for each OS. > > I will have results on ia64, ARMv5, ARMv7 and 3 MIPS ABIs in the next day > or two. > > Looks good to me. > -Paul > > > On Wed, Aug 13, 2014 at 1:37 PM, Jeff Squyres (jsquyres) < > jsquy...@cisco.com> wrote: > >> Please test! Ralph would like to release after the teleconf next Tuesday: >> >> http://www.open-mpi.org/software/ompi/v1.8/ >> >> Changes since last rc: >> >> - Fix cascading/over-quoting in some cases with the rsh/ssh-based >> launcher. Thanks to multiple users for raising the issue. >> - Properly add support for gfortran 4.9 ignore TKR pragma (it was >> erroneously only partially added in v1.7.5). Thanks to Marcus >> Daniels for raising the issue. >> - Update/improve help messages in the usnic BTL. >> - Resolve a race condition in MPI_Abort. >> - Fix obscure cases where static linking from wrapper compilers would >> fail. >> - Clarify the configure --help message about when OpenSHMEM is >> enabled/disabled by default. Thanks to Paul Hargrove for the >> suggestion. >> - Align pages properly where relevant. Thanks to Paul Hargrove for >> identifying the issue. >> - Various compiler warning and minor fixes for OpenBSD, FreeBSD, and >> Solaris/SPARC. Thanks to Paul Hargrove for the patches. >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> 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/08/15640.php >> > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > ___ > 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/08/15647.php >
Re: [OMPI devel] [1.8.2rc4] build failure with --enable-osx-builtin-atomics
Done - thanks! On Wed, Aug 13, 2014 at 9:06 PM, George Bosilca wrote: > The atomic.h file should also be trimmed of the SPARC relique. > > George. > > > Index: opal/include/opal/sys/atomic.h > === > --- opal/include/opal/sys/atomic.h (revision 32531) > +++ opal/include/opal/sys/atomic.h (working copy) > @@ -162,8 +162,6 @@ > #include "opal/sys/powerpc/atomic.h" > #elif OPAL_ASSEMBLY_ARCH == OMPI_POWERPC64 > #include "opal/sys/powerpc/atomic.h" > -#elif OPAL_ASSEMBLY_ARCH == OMPI_SPARC > -#include "opal/sys/sparc/atomic.h" > #elif OPAL_ASSEMBLY_ARCH == OMPI_SPARCV9_32 > #include "opal/sys/sparcv9/atomic.h" > #elif OPAL_ASSEMBLY_ARCH == OMPI_SPARCV9_64 > > > On Thu, Aug 14, 2014 at 12:01 AM, Paul Hargrove > wrote: > >> Fix confirmed using the nightly tarball (v1.8rc5r32531). >> >> -Paul >> >> >> On Wed, Aug 13, 2014 at 6:16 PM, Ralph Castain wrote: >> >>> Thanks Paul - fixed in r32530 >>> >>> >>> >>> On Wed, Aug 13, 2014 at 2:42 PM, Paul Hargrove >>> wrote: >>> When configured with --enable-osx-builtin-atomics Making all in asm CC asm.lo In file included from /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/asm/asm.c:21: /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/include/opal/sys/atomic.h:145:10: fatal error: 'opal/sys/osx/atomic.h' file not found #include "opal/sys/osx/atomic.h" ^ 1 error generated. I reported the same issue to George in the trunk last week. So, I am 95% certain one just needs to cmr r32390 (commit msg == 'Dont miss the Os X atomics on "make dist"') -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 ___ 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/08/15642.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/08/15644.php >>> >> >> >> >> -- >> Paul H. Hargrove phhargr...@lbl.gov >> Future Technologies Group >> Computer and Data Sciences Department Tel: +1-510-495-2352 >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >> >> ___ >> 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/08/15645.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/08/15646.php >
Re: [OMPI devel] 1.8.4rc4 is out
I have completed testing the majority of the platforms I have access to. The only issue that is not already known to exist in earlier releases was the missing osx/atomic.h, for which Ralph promptly merged George's fix. If I include the re-tested osx-atomics (which passes w/ 1.8.2rc5r32531), I have success on 75 distinct configurations which include x86, x86-64, sparc-v8+, sparc64-v9, ppc32 and ppc64 ABIs with various releases of Linux, Mac OS X, Solaris, FreeBSD, NetBSD and OpenBSD, with all sorts of compilers, and static linking (w/o romio :-)) on at least one configuration for each OS. I will have results on ia64, ARMv5, ARMv7 and 3 MIPS ABIs in the next day or two. Looks good to me. -Paul On Wed, Aug 13, 2014 at 1:37 PM, Jeff Squyres (jsquyres) wrote: > Please test! Ralph would like to release after the teleconf next Tuesday: > > http://www.open-mpi.org/software/ompi/v1.8/ > > Changes since last rc: > > - Fix cascading/over-quoting in some cases with the rsh/ssh-based > launcher. Thanks to multiple users for raising the issue. > - Properly add support for gfortran 4.9 ignore TKR pragma (it was > erroneously only partially added in v1.7.5). Thanks to Marcus > Daniels for raising the issue. > - Update/improve help messages in the usnic BTL. > - Resolve a race condition in MPI_Abort. > - Fix obscure cases where static linking from wrapper compilers would > fail. > - Clarify the configure --help message about when OpenSHMEM is > enabled/disabled by default. Thanks to Paul Hargrove for the > suggestion. > - Align pages properly where relevant. Thanks to Paul Hargrove for > identifying the issue. > - Various compiler warning and minor fixes for OpenBSD, FreeBSD, and > Solaris/SPARC. Thanks to Paul Hargrove for the patches. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/08/15640.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Re: [OMPI devel] [1.8.2rc4] build failure with --enable-osx-builtin-atomics
The atomic.h file should also be trimmed of the SPARC relique. George. Index: opal/include/opal/sys/atomic.h === --- opal/include/opal/sys/atomic.h (revision 32531) +++ opal/include/opal/sys/atomic.h (working copy) @@ -162,8 +162,6 @@ #include "opal/sys/powerpc/atomic.h" #elif OPAL_ASSEMBLY_ARCH == OMPI_POWERPC64 #include "opal/sys/powerpc/atomic.h" -#elif OPAL_ASSEMBLY_ARCH == OMPI_SPARC -#include "opal/sys/sparc/atomic.h" #elif OPAL_ASSEMBLY_ARCH == OMPI_SPARCV9_32 #include "opal/sys/sparcv9/atomic.h" #elif OPAL_ASSEMBLY_ARCH == OMPI_SPARCV9_64 On Thu, Aug 14, 2014 at 12:01 AM, Paul Hargrove wrote: > Fix confirmed using the nightly tarball (v1.8rc5r32531). > > -Paul > > > On Wed, Aug 13, 2014 at 6:16 PM, Ralph Castain wrote: > >> Thanks Paul - fixed in r32530 >> >> >> >> On Wed, Aug 13, 2014 at 2:42 PM, Paul Hargrove >> wrote: >> >>> When configured with --enable-osx-builtin-atomics >>> >>> Making all in asm >>> CC asm.lo >>> In file included from >>> /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/asm/asm.c:21: >>> /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/include/opal/sys/atomic.h:145:10: >>> fatal error: 'opal/sys/osx/atomic.h' file not found >>> #include "opal/sys/osx/atomic.h" >>> ^ >>> 1 error generated. >>> >>> I reported the same issue to George in the trunk last week. >>> So, I am 95% certain one just needs to cmr r32390 (commit msg == 'Dont >>> miss the Os X atomics on "make dist"') >>> >>> >>> -Paul >>> >>> -- >>> Paul H. Hargrove phhargr...@lbl.gov >>> Future Technologies Group >>> Computer and Data Sciences Department Tel: +1-510-495-2352 >>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >>> >>> ___ >>> 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/08/15642.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/08/15644.php >> > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > ___ > 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/08/15645.php >
Re: [OMPI devel] [1.8.2rc4] build failure with --enable-osx-builtin-atomics
Fix confirmed using the nightly tarball (v1.8rc5r32531). -Paul On Wed, Aug 13, 2014 at 6:16 PM, Ralph Castain wrote: > Thanks Paul - fixed in r32530 > > > > On Wed, Aug 13, 2014 at 2:42 PM, Paul Hargrove wrote: > >> When configured with --enable-osx-builtin-atomics >> >> Making all in asm >> CC asm.lo >> In file included from >> /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/asm/asm.c:21: >> /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/include/opal/sys/atomic.h:145:10: >> fatal error: 'opal/sys/osx/atomic.h' file not found >> #include "opal/sys/osx/atomic.h" >> ^ >> 1 error generated. >> >> I reported the same issue to George in the trunk last week. >> So, I am 95% certain one just needs to cmr r32390 (commit msg == 'Dont >> miss the Os X atomics on "make dist"') >> >> >> -Paul >> >> -- >> Paul H. Hargrove phhargr...@lbl.gov >> Future Technologies Group >> Computer and Data Sciences Department Tel: +1-510-495-2352 >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >> >> ___ >> 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/08/15642.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/08/15644.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
