[OMPI devel] 1.7.4rc1 test failure : cygwin 64 bit
Failures on cygwin 64bit with gcc-4.8.2. Notes: - cygwin 32bit gives no failure - These failures are not new, they were also present in openmpi-1.7.3-1 and previous - --> Testing atomic_spinlock_noinline.exe /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 6476 Segmentation fault (core dumped) $* $threads - 1 threads: Failed /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 6680 Segmentation fault (core dumped) $* $threads - 2 threads: Failed - 4 threads: Passed - 5 threads: Passed - 8 threads: Passed FAIL: atomic_spinlock_noinline.exe --> Testing atomic_math.exe - 1 threads: Passed - 2 threads: Passed - 4 threads: Passed - 5 threads: Passed - 8 threads: Passed PASS: atomic_math.exe --> Testing atomic_math_noinline.exe /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 6676 Segmentation fault (core dumped) $* $threads - 1 threads: Failed - 2 threads: Passed - 4 threads: Passed /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 6976 Segmentation fault (core dumped) $* $threads - 5 threads: Failed - 8 threads: Passed FAIL: atomic_math_noinline.exe --> Testing atomic_cmpset.exe - 1 threads: Passed - 2 threads: Passed - 4 threads: Passed - 5 threads: Passed - 8 threads: Passed PASS: atomic_cmpset.exe --> Testing atomic_cmpset_noinline.exe assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", line 105, function: main /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 6248 Aborted (core dumped) $* $threads - 1 threads: Failed assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", line 105, function: main /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 2556 Aborted (core dumped) $* $threads - 2 threads: Failed assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", line 105, function: main /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 6164 Aborted (core dumped) $* $threads - 4 threads: Failed assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", line 105, function: main /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 5312 Aborted (core dumped) $* $threads - 5 threads: Failed assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", line 105, function: main /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: line 8: 7948 Aborted (core dumped) $* $threads - 8 threads: Failed FAIL: atomic_cmpset_noinline.exe 3 of 8 tests failed
Re: [OMPI devel] 1.7.4rc1 test failure : cygwin 64 bit
Can you try with the latest trunk please? Also if things are not going well with the trunk please provide the opal_config.h file. Thanks, George. On Jan 7, 2014, at 14:19 , marco atzeri wrote: > Failures on cygwin 64bit with gcc-4.8.2. > Notes: > - cygwin 32bit gives no failure > - These failures are not new, they were also present in openmpi-1.7.3-1 > and previous > > - > --> Testing atomic_spinlock_noinline.exe > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 6476 Segmentation fault (core dumped) $* $threads >- 1 threads: Failed > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 6680 Segmentation fault (core dumped) $* $threads >- 2 threads: Failed >- 4 threads: Passed >- 5 threads: Passed >- 8 threads: Passed > FAIL: atomic_spinlock_noinline.exe > --> Testing atomic_math.exe >- 1 threads: Passed >- 2 threads: Passed >- 4 threads: Passed >- 5 threads: Passed >- 8 threads: Passed > PASS: atomic_math.exe > --> Testing atomic_math_noinline.exe > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 6676 Segmentation fault (core dumped) $* $threads >- 1 threads: Failed >- 2 threads: Passed >- 4 threads: Passed > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 6976 Segmentation fault (core dumped) $* $threads >- 5 threads: Failed >- 8 threads: Passed > FAIL: atomic_math_noinline.exe > --> Testing atomic_cmpset.exe >- 1 threads: Passed >- 2 threads: Passed >- 4 threads: Passed >- 5 threads: Passed >- 8 threads: Passed > PASS: atomic_cmpset.exe > --> Testing atomic_cmpset_noinline.exe > assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file > "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", > line 105, function: main > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 6248 Aborted (core dumped) $* $threads >- 1 threads: Failed > assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file > "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", > line 105, function: main > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 2556 Aborted (core dumped) $* $threads >- 2 threads: Failed > assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file > "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", > line 105, function: main > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 6164 Aborted (core dumped) $* $threads >- 4 threads: Failed > assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file > "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", > line 105, function: main > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 5312 Aborted (core dumped) $* $threads >- 5 threads: Failed > assertion "opal_atomic_cmpset_32(&vol32, old32, new32) == 1" failed: file > "/pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/atomic_cmpset_noinline.c", > line 105, function: main > /pub/devel/openmpi/openmpi-1.7.4rc1-1/src/openmpi-1.7.4rc1/test/asm/run_tests: > line 8: 7948 Aborted (core dumped) $* $threads >- 8 threads: Failed > FAIL: atomic_cmpset_noinline.exe > > 3 of 8 tests failed > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] return value of opal_compress_base_register() in opal/mca/compress/base/compress_base_open.c
Either would be fine with me. If you left in the verbose message then it
might be a bit confusing to any user that might see it.
On Fri, Jan 3, 2014 at 9:13 AM, Ralph Castain wrote:
> That would work. Alternatively, you could try just returning OPAL_SUCCESS
> in place of OPAL_ERR_NOT_AVAILABLE. This would still avoid opening the
> components for no reason (thus saving some memory) while not causing
> opal_init to abort.
>
>
> On Jan 3, 2014, at 3:19 AM, Adrian Reber wrote:
>
> > So removing all output like in this patch would be ok?
> >
> > diff --git a/opal/mca/compress/base/compress_base_open.c
> b/opal/mca/compress/base/compress_base_open.c
> > index a09fe59..f487752 100644
> > --- a/opal/mca/compress/base/compress_base_open.c
> > +++ b/opal/mca/compress/base/compress_base_open.c
> > @@ -14,13 +14,9 @@
> >
> > #include "opal_config.h"
> >
> > -#include
> > -#include "opal/mca/mca.h"
> > #include "opal/mca/base/base.h"
> > #include "opal/include/opal/constants.h"
> > -#include "opal/mca/compress/compress.h"
> > #include "opal/mca/compress/base/base.h"
> > -#include "opal/util/output.h"
> >
> > #include "opal/mca/compress/base/static-components.h"
> >
> > @@ -45,13 +41,6 @@ MCA_BASE_FRAMEWORK_DECLARE(opal, compress, NULL,
> opal_compress_base_register, op
> >
> > static int opal_compress_base_register (mca_base_register_flag_t flags)
> > {
> > -/* Compression currently only used with C/R */
> > -if( !opal_cr_is_enabled ) {
> > -opal_output_verbose(10,
> opal_compress_base_framework.framework_output,
> > -"compress:open: FT is not enabled,
> skipping!");
> > -return OPAL_ERR_NOT_AVAILABLE;
> > -}
> > -
> > return OPAL_SUCCESS;
> > }
> >
> > @@ -61,13 +50,6 @@ static int opal_compress_base_register
> (mca_base_register_flag_t flags)
> > */
> > int opal_compress_base_open(mca_base_open_flag_t flags)
> > {
> > -/* Compression currently only used with C/R */
> > -if( !opal_cr_is_enabled ) {
> > -opal_output_verbose(10,
> opal_compress_base_framework.framework_output,
> > -"compress:open: FT is not enabled,
> skipping!");
> > -return OPAL_SUCCESS;
> > -}
> > -
> > /* Open up all available components */
> > return mca_base_framework_components_open
> (&opal_compress_base_framework, flags);
> > }
> >
> >
> >
> > On Thu, Jan 02, 2014 at 12:32:32PM -0500, Josh Hursey wrote:
> >> I think the only reason I protected that framework is to reduce the
> >> overhead of an application using a build of Open MPI with CR support,
> but
> >> no enabling it at runtime. Nothing in the compress framework depends on
> the
> >> CR infrastructure (although the CR infrastructure can use the compress
> >> framework if the user chooses to). So I bet we can remove the protection
> >> altogether and be fine.
> >>
> >> So I think this patch is fine. I might also go as far as removing the
> 'if'
> >> block altogether as the protection should not been needed any longer.
> >>
> >> Thanks,
> >> Josh
> >>
> >>
> >>
> >> On Fri, Dec 27, 2013 at 3:46 PM, Adrian Reber wrote:
> >>
> >>> Right now the C/R code fails because of a change introduced in
> >>> opal/mca/compress/base/compress_base_open.c in 2013 with commit
> >>>
> >>> git 734c724ff76d9bf814f3ab0396bcd9ee6fddcd1b
> >>> svn r28239
> >>>
> >>>Update OPAL frameworks to use the MCA framework system.
> >>>
> >>> This commit changed a lot but also the return value of the function
> from
> >>> OPAL_SUCCESS to OPAL_ERR_NOT_AVAILABLE. With following patch I can make
> >>> it work again:
> >>>
> >>> diff --git a/opal/mca/compress/base/compress_base_open.c
> >>> b/opal/mca/compress/base/compress_base_open.c
> >>> index a09fe59..69eabfa 100644
> >>> --- a/opal/mca/compress/base/compress_base_open.c
> >>> +++ b/opal/mca/compress/base/compress_base_open.c
> >>> @@ -45,11 +45,11 @@ MCA_BASE_FRAMEWORK_DECLARE(opal, compress, NULL,
> >>> opal_compress_base_register, op
> >>>
> >>> static int opal_compress_base_register (mca_base_register_flag_t flags)
> >>> {
> >>> /* Compression currently only used with C/R */
> >>> if( !opal_cr_is_enabled ) {
> >>> opal_output_verbose(10,
> >>> opal_compress_base_framework.framework_output,
> >>> "compress:open: FT is not enabled,
> >>> skipping!");
> >>> -return OPAL_ERR_NOT_AVAILABLE;
> >>> +return OPAL_SUCCESS;
> >>> }
> >>>
> >>> return OPAL_SUCCESS;
> >>>
> >>>
> >>> My question is if OPAL_ERR_NOT_AVAILABLE is indeed the correct return
> value
> >>> and the function calling opal_compress_base_register() should actually
> >>> handle OPAL_ERR_NOT_AVAILABLE or if returning OPAL_SUCCESS is still the
> >>> right
> >>> return value?
> >>>
> >>>Adrian
> >>> ___
> >>> devel mailing list
> >>> de...@open-mpi.org
> >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>
> >>
> >>
> >>
> >> --
> >> Joshua Hurse
Re: [OMPI devel] return value of opal_compress_base_register() in opal/mca/compress/base/compress_base_open.c
I have commited fixes for
opal/mca/compress/base/compress_base_open.c and
opal/mca/crs/base/crs_base_open.c
which return OPAL_SUCCESS but do not open the components if CR is
disabled.
Adrian
On Tue, Jan 07, 2014 at 01:43:00PM -0600, Josh Hursey wrote:
> Either would be fine with me. If you left in the verbose message then it
> might be a bit confusing to any user that might see it.
>
>
> On Fri, Jan 3, 2014 at 9:13 AM, Ralph Castain wrote:
>
> > That would work. Alternatively, you could try just returning OPAL_SUCCESS
> > in place of OPAL_ERR_NOT_AVAILABLE. This would still avoid opening the
> > components for no reason (thus saving some memory) while not causing
> > opal_init to abort.
> >
> >
> > On Jan 3, 2014, at 3:19 AM, Adrian Reber wrote:
> >
> > > So removing all output like in this patch would be ok?
> > >
> > > diff --git a/opal/mca/compress/base/compress_base_open.c
> > b/opal/mca/compress/base/compress_base_open.c
> > > index a09fe59..f487752 100644
> > > --- a/opal/mca/compress/base/compress_base_open.c
> > > +++ b/opal/mca/compress/base/compress_base_open.c
> > > @@ -14,13 +14,9 @@
> > >
> > > #include "opal_config.h"
> > >
> > > -#include
> > > -#include "opal/mca/mca.h"
> > > #include "opal/mca/base/base.h"
> > > #include "opal/include/opal/constants.h"
> > > -#include "opal/mca/compress/compress.h"
> > > #include "opal/mca/compress/base/base.h"
> > > -#include "opal/util/output.h"
> > >
> > > #include "opal/mca/compress/base/static-components.h"
> > >
> > > @@ -45,13 +41,6 @@ MCA_BASE_FRAMEWORK_DECLARE(opal, compress, NULL,
> > opal_compress_base_register, op
> > >
> > > static int opal_compress_base_register (mca_base_register_flag_t flags)
> > > {
> > > -/* Compression currently only used with C/R */
> > > -if( !opal_cr_is_enabled ) {
> > > -opal_output_verbose(10,
> > opal_compress_base_framework.framework_output,
> > > -"compress:open: FT is not enabled,
> > skipping!");
> > > -return OPAL_ERR_NOT_AVAILABLE;
> > > -}
> > > -
> > > return OPAL_SUCCESS;
> > > }
> > >
> > > @@ -61,13 +50,6 @@ static int opal_compress_base_register
> > (mca_base_register_flag_t flags)
> > > */
> > > int opal_compress_base_open(mca_base_open_flag_t flags)
> > > {
> > > -/* Compression currently only used with C/R */
> > > -if( !opal_cr_is_enabled ) {
> > > -opal_output_verbose(10,
> > opal_compress_base_framework.framework_output,
> > > -"compress:open: FT is not enabled,
> > skipping!");
> > > -return OPAL_SUCCESS;
> > > -}
> > > -
> > > /* Open up all available components */
> > > return mca_base_framework_components_open
> > (&opal_compress_base_framework, flags);
> > > }
> > >
> > >
> > >
> > > On Thu, Jan 02, 2014 at 12:32:32PM -0500, Josh Hursey wrote:
> > >> I think the only reason I protected that framework is to reduce the
> > >> overhead of an application using a build of Open MPI with CR support,
> > but
> > >> no enabling it at runtime. Nothing in the compress framework depends on
> > the
> > >> CR infrastructure (although the CR infrastructure can use the compress
> > >> framework if the user chooses to). So I bet we can remove the protection
> > >> altogether and be fine.
> > >>
> > >> So I think this patch is fine. I might also go as far as removing the
> > 'if'
> > >> block altogether as the protection should not been needed any longer.
> > >>
> > >> Thanks,
> > >> Josh
> > >>
> > >>
> > >>
> > >> On Fri, Dec 27, 2013 at 3:46 PM, Adrian Reber wrote:
> > >>
> > >>> Right now the C/R code fails because of a change introduced in
> > >>> opal/mca/compress/base/compress_base_open.c in 2013 with commit
> > >>>
> > >>> git 734c724ff76d9bf814f3ab0396bcd9ee6fddcd1b
> > >>> svn r28239
> > >>>
> > >>>Update OPAL frameworks to use the MCA framework system.
> > >>>
> > >>> This commit changed a lot but also the return value of the function
> > from
> > >>> OPAL_SUCCESS to OPAL_ERR_NOT_AVAILABLE. With following patch I can make
> > >>> it work again:
> > >>>
> > >>> diff --git a/opal/mca/compress/base/compress_base_open.c
> > >>> b/opal/mca/compress/base/compress_base_open.c
> > >>> index a09fe59..69eabfa 100644
> > >>> --- a/opal/mca/compress/base/compress_base_open.c
> > >>> +++ b/opal/mca/compress/base/compress_base_open.c
> > >>> @@ -45,11 +45,11 @@ MCA_BASE_FRAMEWORK_DECLARE(opal, compress, NULL,
> > >>> opal_compress_base_register, op
> > >>>
> > >>> static int opal_compress_base_register (mca_base_register_flag_t flags)
> > >>> {
> > >>> /* Compression currently only used with C/R */
> > >>> if( !opal_cr_is_enabled ) {
> > >>> opal_output_verbose(10,
> > >>> opal_compress_base_framework.framework_output,
> > >>> "compress:open: FT is not enabled,
> > >>> skipping!");
> > >>> -return OPAL_ERR_NOT_AVAILABLE;
> > >>> +return OPAL_SUCCESS;
> > >>> }
> > >>>
> > >>> return OPAL_SUCCE
[OMPI devel] [Patch] For Fortran, support GCC/gfortran 4.9's TYPE(*) with NO_ARG_CHECK
Hello, I'd like to see the following patch to be included in Open MPI, which enabled interface checking also with GCC's gfortran. While TYPE(*), DIMENSION(*) is already tested for, it cannot be used for scalars (and "TYPE(*)" cannot be used with arrays). [Those were added in GCC 4.8, which diagnoses the rank mismatch. Fortran 2015 (?) will add support for both scalars and dimensions.] In GCC 4.9, gfortran joins other compilers by supporting a directive which disables the argument check (type, kind, rank checking: TKR): NO_ARG_CHECK. The attached patch does so. The original version has been added 8 months ago to https://bitbucket.org/jsquyres/mpi3-fortran/commits/243ffae9f63ffc8fcdfdc604796ef290963ea1c4 - but as it hasn't been merged to the Open MPI, I submit it with this email (rediffed with some additional cases). I'd be delighted if the patch could be applied to the trunk - and possibly even be backported to 1.7. (I think it also applies to 1.6 but I haven't checked.) Tobias Index: config/ompi_fortran_check_ignore_tkr.m4 === --- config/ompi_fortran_check_ignore_tkr.m4 (Revision 30138) +++ config/ompi_fortran_check_ignore_tkr.m4 (Arbeitskopie) @@ -76,6 +76,12 @@ [TYPE(*), DIMENSION(*)], [happy=1], [happy=0]) +# GCC compilers +AS_IF([test $happy -eq 0], + [OMPI_FORTRAN_CHECK_IGNORE_TKR_SUB( + [!GCC\$ ATTRIBUTES NO_ARG_CHECK ::], [type(*), dimension(*)], + [!GCC\$ ATTRIBUTES NO_ARG_CHECK], + [happy=1], [happy=0])]) # Intel compilers AS_IF([test $happy -eq 0], [OMPI_FORTRAN_CHECK_IGNORE_TKR_SUB( Index: ompi/mpi/fortran/base/mpi-f08-interfaces.F90 === --- ompi/mpi/fortran/base/mpi-f08-interfaces.F90 (Revision 30138) +++ ompi/mpi/fortran/base/mpi-f08-interfaces.F90 (Arbeitskopie) @@ -23,6 +23,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -39,6 +40,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -55,6 +57,7 @@ subroutine MPI_Buffer_attach_f08(buffer,size,ierror) implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buffer + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buffer !$PRAGMA IGNORE_TKR buffer !DIR$ IGNORE_TKR buffer !IBM* IGNORE_TKR buffer @@ -68,6 +71,7 @@ subroutine MPI_Buffer_detach_f08(buffer_addr,size,ierror) implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buffer_addr + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buffer_addr !$PRAGMA IGNORE_TKR buffer_addr !DIR$ IGNORE_TKR buffer_addr !IBM* IGNORE_TKR buffer_addr @@ -102,6 +106,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -131,6 +136,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -148,6 +154,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -165,6 +172,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -182,6 +190,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -210,6 +219,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Status implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -227,6 +237,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request implicit none !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf + !GCC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf !DIR$ IGNORE_TKR buf !IBM* IGNORE_TKR buf @@ -264,6 +275,7 @@ use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm implicit none !
[OMPI devel] RFC: Drop all mpirun single-dash multi-letter CLI options (except -np)
WHAT: Drop mpirun single-dash CLI options such as -bynode (but keep the
double-dash equivalents, like --bynode)
WHY: It's a well-established de facto CLI option standard:
"-" is used for single-letter options
"--" is used for tokenized options
WHERE: probably mostly in orte/tools/orterun
WHEN: 1.9
TIMEOUT: Teleconf, Tuesday 21 Jan 2014
MORE DETAIL:
We've supported single- and double-dash variants of many mpirun options for
several years (e.g., --bynode and -bynode). With the exception of "-np",
there's really no reason we should support the single-dash versions ("-np" is
pretty universally expected in the MPI/HPC world; I don't think we'll ever be
able to get rid of it).
Let's deprecate all single-dash options (except -np) in 1.7.5/1.8 and eliminate
them in 1.9. Specifically, let's do something like this in 1.7.5:
-
$ shell mpirun -bynode -np 4 a.out
You used the "-bynode" option to mpirun, which, although it still functions
as you would expect it to, is now deprecated. The exactly-equivalent "--bynode"
option replaces the "-bynode" option.
*** NOTE THAT -bynode OPTION WILL DISAPPEAR IN A FUTURE VERSION OF OPEN MPI!
***
To be compatible with future versions of Open MPI, use the "--bynode" option.
If you can't easily change your mpirun command line, then you can set the MCA
parameter orterun_i_promise_to_update_my_cli_options_before_ompi_1_9 to 1,
which will suppress this message.
-
This gives the user two clear options:
1. Update from -foo to --foo to be forward compatible
2. Set an MCA parameter to suppress the message, but risk not being forward
compatible
Then, on trunk/v1.9, we remove all the single-dash options.
Comments?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: Drop all mpirun single-dash multi-letter CLI options (except -np)
+1
On Jan 7, 2014, at 1:49 PM, Jeff Squyres (jsquyres) wrote:
> WHAT: Drop mpirun single-dash CLI options such as -bynode (but keep the
> double-dash equivalents, like --bynode)
>
> WHY: It's a well-established de facto CLI option standard:
> "-" is used for single-letter options
> "--" is used for tokenized options
>
> WHERE: probably mostly in orte/tools/orterun
>
> WHEN: 1.9
>
> TIMEOUT: Teleconf, Tuesday 21 Jan 2014
>
> MORE DETAIL:
>
> We've supported single- and double-dash variants of many mpirun options for
> several years (e.g., --bynode and -bynode). With the exception of "-np",
> there's really no reason we should support the single-dash versions ("-np" is
> pretty universally expected in the MPI/HPC world; I don't think we'll ever be
> able to get rid of it).
>
> Let's deprecate all single-dash options (except -np) in 1.7.5/1.8 and
> eliminate them in 1.9. Specifically, let's do something like this in 1.7.5:
>
> -
> $ shell mpirun -bynode -np 4 a.out
>
> You used the "-bynode" option to mpirun, which, although it still functions
> as you would expect it to, is now deprecated. The exactly-equivalent
> "--bynode"
> option replaces the "-bynode" option.
>
> *** NOTE THAT -bynode OPTION WILL DISAPPEAR IN A FUTURE VERSION OF OPEN MPI!
> ***
>
> To be compatible with future versions of Open MPI, use the "--bynode" option.
>
> If you can't easily change your mpirun command line, then you can set the MCA
> parameter orterun_i_promise_to_update_my_cli_options_before_ompi_1_9 to 1,
> which will suppress this message.
>
> -
>
> This gives the user two clear options:
>
> 1. Update from -foo to --foo to be forward compatible
> 2. Set an MCA parameter to suppress the message, but risk not being forward
> compatible
>
> Then, on trunk/v1.9, we remove all the single-dash options.
>
> Comments?
>
> --
> 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
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] RFC: OB1 optimizations
What: Push some ob1 optimizations to the trunk and 1.7.5.
What: This patch contains two optimizations:
- Introduce a fast send path for blocking send calls. This path uses
the btl sendi function to put the data on the wire without the need
for setting up a send request. In the case of btl/vader this can
also avoid allocating/initializing a new fragment. With btl/vader
this optimization improves small message latency by 50-200ns in
ping-pong type benchmarks. Larger messages may take a small hit in
the range of 10-20ns.
- Use a stack-allocated receive request for blocking recieves. This
optimization saves the extra instructions associated with accessing
the receive request free list. I was able to get another 50-200ns
improvement in the small-message ping-pong with this optimization. I
see no hit for larger messages.
When: These changes touch the critical path in ob1 and are targeted for
1.7.5. As such I will set a moderately long timeout. Timeout set for
next Friday (Jan 17).
Some results from osu_latency on haswell:
hjelmn@cn143 pt2pt]$ mpirun -n 2 --bind-to core -mca btl vader,self
./osu_latency
# OSU MPI Latency Test v4.0.1
# Size Latency (us)
0 0.11
1 0.14
2 0.14
4 0.14
8 0.14
16 0.14
32 0.15
64 0.18
128 0.36
256 0.37
512 0.46
10240.56
20480.80
40961.12
81921.68
16384 2.98
32768 5.10
65536 8.12
131072 14.07
262144 25.30
524288 47.40
104857691.71
2097152 195.56
4194304 487.05
Patch Attached.
-Nathan
diff --git a/ompi/mca/pml/ob1/pml_ob1_irecv.c b/ompi/mca/pml/ob1/pml_ob1_irecv.c
index c85d8f6..ee4812d 100644
--- a/ompi/mca/pml/ob1/pml_ob1_irecv.c
+++ b/ompi/mca/pml/ob1/pml_ob1_irecv.c
@@ -1,3 +1,4 @@
+/* -*- Mode: C; c-basic-offset:4 ; indent-tabs-mode:nil -*- */
/*
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
* University Research and Technology
@@ -9,7 +10,7 @@
* University of Stuttgart. All rights reserved.
* Copyright (c) 2004-2005 The Regents of the University of California.
* All rights reserved.
- * Copyright (c) 2007 Los Alamos National Security, LLC. All rights
+ * Copyright (c) 2007-2013 Los Alamos National Security, LLC. All rights
* reserved.
* Copyright (c) 2010-2012 Oracle and/or its affiliates. All rights reserved.
* Copyright (c) 2011 Sandia National Laboratories. All rights reserved.
@@ -87,28 +88,29 @@ int mca_pml_ob1_recv(void *addr,
struct ompi_communicator_t *comm,
ompi_status_public_t * status)
{
+mca_pml_ob1_recv_request_t recvreq;
int rc;
-mca_pml_ob1_recv_request_t *recvreq;
-MCA_PML_OB1_RECV_REQUEST_ALLOC(recvreq);
-if (NULL == recvreq)
-return OMPI_ERR_TEMP_OUT_OF_RESOURCE;
-MCA_PML_OB1_RECV_REQUEST_INIT(recvreq,
- addr,
- count, datatype, src, tag, comm, false);
+OBJ_CONSTRUCT(&recvreq, mca_pml_ob1_recv_request_t);
+
+MCA_PML_OB1_RECV_REQUEST_INIT(&recvreq, addr, count, datatype,
+ src, tag, comm, false);
PERUSE_TRACE_COMM_EVENT (PERUSE_COMM_REQ_ACTIVATE,
- &((recvreq)->req_recv.req_base),
+ &(recvreq.req_recv.req_base),
PERUSE_RECV);
-MCA_PML_OB1_RECV_REQUEST_START(recvreq);
-ompi_request_wait_completion(&recvreq->req_recv.req_base.req_ompi);
+MCA_PML_OB1_RECV_REQUEST_START(&recvreq);
+ompi_request_wait_completion(&recvreq.req_recv.req_base.req_ompi);
if (NULL != status) { /* return status */
-*status = recvreq->req_recv.req_base.req_ompi.req_status;
+*status = recvreq.req_recv.req_base.req_ompi.req_status;
}
-rc = recvreq->req_recv.req_base.req_ompi.req_status.MPI_ERROR;
-ompi_request_free( (ompi_request_t**)&recvreq );
+
+rc = recvreq.req_recv.req_base.req_ompi.req_status.MPI_ERROR;
+
+OBJ_DESTRUCT(&recvreq);
+
return rc;
}
diff --git a/ompi/mca/pml/ob1/pml_ob1_isend.c b/ompi/mca/pml/ob1/pml_ob1_isend.c
index c689981..bbff946 100644
--- a/ompi/mca/pml/ob1/pml_ob1_isend.c
+++ b/ompi/mca/pml/ob1/pml_ob1_isend.c
@@ -1,3 +1,4 @@
+/* -*- Mode: C; c-basic-offset:4 ; indent-tabs-mode:nil -*- */
/*
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
* University Research and Technology
@@ -9,7 +10,7 @@
*
Re: [OMPI devel] RFC: Drop all mpirun single-dash multi-letter CLI options (except -np)
+1. Single dashed long names drive me nuts.
-Nathan
On Tue, Jan 07, 2014 at 03:17:11PM -0800, Ralph Castain wrote:
> +1
>
> On Jan 7, 2014, at 1:49 PM, Jeff Squyres (jsquyres)
> wrote:
>
> > WHAT: Drop mpirun single-dash CLI options such as -bynode (but keep the
> > double-dash equivalents, like --bynode)
> >
> > WHY: It's a well-established de facto CLI option standard:
> > "-" is used for single-letter options
> > "--" is used for tokenized options
> >
> > WHERE: probably mostly in orte/tools/orterun
> >
> > WHEN: 1.9
> >
> > TIMEOUT: Teleconf, Tuesday 21 Jan 2014
> >
> > MORE DETAIL:
> >
> > We've supported single- and double-dash variants of many mpirun options for
> > several years (e.g., --bynode and -bynode). With the exception of "-np",
> > there's really no reason we should support the single-dash versions ("-np"
> > is pretty universally expected in the MPI/HPC world; I don't think we'll
> > ever be able to get rid of it).
> >
> > Let's deprecate all single-dash options (except -np) in 1.7.5/1.8 and
> > eliminate them in 1.9. Specifically, let's do something like this in 1.7.5:
> >
> > -
> > $ shell mpirun -bynode -np 4 a.out
> >
> > You used the "-bynode" option to mpirun, which, although it still functions
> > as you would expect it to, is now deprecated. The exactly-equivalent
> > "--bynode"
> > option replaces the "-bynode" option.
> >
> > *** NOTE THAT -bynode OPTION WILL DISAPPEAR IN A FUTURE VERSION OF OPEN
> > MPI! ***
> >
> > To be compatible with future versions of Open MPI, use the "--bynode"
> > option.
> >
> > If you can't easily change your mpirun command line, then you can set the
> > MCA
> > parameter orterun_i_promise_to_update_my_cli_options_before_ompi_1_9 to 1,
> > which will suppress this message.
> >
> > -
> >
> > This gives the user two clear options:
> >
> > 1. Update from -foo to --foo to be forward compatible
> > 2. Set an MCA parameter to suppress the message, but risk not being forward
> > compatible
> >
> > Then, on trunk/v1.9, we remove all the single-dash options.
> >
> > Comments?
> >
> > --
> > 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
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
pgps90JY1VDwX.pgp
Description: PGP signature
Re: [OMPI devel] RFC: OB1 optimizations
Overall it looks good. It would be helpful to validate performance numbers for other interconnects as well. -Pasha > -Original Message- > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Nathan > Hjelm > Sent: Tuesday, January 07, 2014 6:45 PM > To: Open MPI Developers List > Subject: [OMPI devel] RFC: OB1 optimizations > > What: Push some ob1 optimizations to the trunk and 1.7.5. > > What: This patch contains two optimizations: > > - Introduce a fast send path for blocking send calls. This path uses > the btl sendi function to put the data on the wire without the need > for setting up a send request. In the case of btl/vader this can > also avoid allocating/initializing a new fragment. With btl/vader > this optimization improves small message latency by 50-200ns in > ping-pong type benchmarks. Larger messages may take a small hit in > the range of 10-20ns. > > - Use a stack-allocated receive request for blocking recieves. This > optimization saves the extra instructions associated with accessing > the receive request free list. I was able to get another 50-200ns > improvement in the small-message ping-pong with this optimization. I > see no hit for larger messages. > > When: These changes touch the critical path in ob1 and are targeted for > 1.7.5. As such I will set a moderately long timeout. Timeout set for > next Friday (Jan 17). > > Some results from osu_latency on haswell: > > hjelmn@cn143 pt2pt]$ mpirun -n 2 --bind-to core -mca btl vader,self > ./osu_latency > # OSU MPI Latency Test v4.0.1 > # Size Latency (us) > 0 0.11 > 1 0.14 > 2 0.14 > 4 0.14 > 8 0.14 > 16 0.14 > 32 0.15 > 64 0.18 > 128 0.36 > 256 0.37 > 512 0.46 > 10240.56 > 20480.80 > 40961.12 > 81921.68 > 16384 2.98 > 32768 5.10 > 65536 8.12 > 131072 14.07 > 262144 25.30 > 524288 47.40 > 104857691.71 > 2097152 195.56 > 4194304 487.05 > > > Patch Attached. > > -Nathan
Re: [OMPI devel] RFC: OB1 optimizations
The local request is not correctly released, leading to assert in debug mode. This is because you avoid calling MCA_PML_BASE_RECV_REQUEST_FINI, fact that leaves the request in an ACTIVE state, condition carefully checked during the call to destructor. I attached a second patch that fixes the issue above, and implement a similar optimization for the blocking send. Unfortunately, this is not enough. The mca_pml_ob1_send_inline optimization is horribly wrong in a multithreaded case as it alter the send_sequence without storing it. If you create a gap in the send_sequence a deadlock will __definitively__ occur. I strongly suggest you turn off the mca_pml_ob1_send_inline optimization on the multithreaded case. All the others optimizations should be safe in all cases. George. ob1_optimization_take2.patch Description: Binary data On Jan 8, 2014, at 01:15 , Shamis, Pavel wrote: > Overall it looks good. It would be helpful to validate performance numbers > for other interconnects as well. > -Pasha > >> -Original Message- >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Nathan >> Hjelm >> Sent: Tuesday, January 07, 2014 6:45 PM >> To: Open MPI Developers List >> Subject: [OMPI devel] RFC: OB1 optimizations >> >> What: Push some ob1 optimizations to the trunk and 1.7.5. >> >> What: This patch contains two optimizations: >> >> - Introduce a fast send path for blocking send calls. This path uses >>the btl sendi function to put the data on the wire without the need >>for setting up a send request. In the case of btl/vader this can >>also avoid allocating/initializing a new fragment. With btl/vader >>this optimization improves small message latency by 50-200ns in >>ping-pong type benchmarks. Larger messages may take a small hit in >>the range of 10-20ns. >> >> - Use a stack-allocated receive request for blocking recieves. This >>optimization saves the extra instructions associated with accessing >>the receive request free list. I was able to get another 50-200ns >>improvement in the small-message ping-pong with this optimization. I >>see no hit for larger messages. >> >> When: These changes touch the critical path in ob1 and are targeted for >> 1.7.5. As such I will set a moderately long timeout. Timeout set for >> next Friday (Jan 17). >> >> Some results from osu_latency on haswell: >> >> hjelmn@cn143 pt2pt]$ mpirun -n 2 --bind-to core -mca btl vader,self >> ./osu_latency >> # OSU MPI Latency Test v4.0.1 >> # Size Latency (us) >> 0 0.11 >> 1 0.14 >> 2 0.14 >> 4 0.14 >> 8 0.14 >> 16 0.14 >> 32 0.15 >> 64 0.18 >> 128 0.36 >> 256 0.37 >> 512 0.46 >> 10240.56 >> 20480.80 >> 40961.12 >> 81921.68 >> 16384 2.98 >> 32768 5.10 >> 65536 8.12 >> 131072 14.07 >> 262144 25.30 >> 524288 47.40 >> 104857691.71 >> 2097152 195.56 >> 4194304 487.05 >> >> >> Patch Attached. >> >> -Nathan > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [Patch] For Fortran, support GCC/gfortran 4.9's TYPE(*) with NO_ARG_CHECK
Many thanks for the reminder; this had totally slipped off my radar. :-( Oy, yes, I added this in my bitbucket forever ago and forgot to bring it to the trunk! :-( It looks like that bitbucket is in bad shape -- I just svn up'ed it, and it no longer compiles. I suspect some conflicts crept in unnoticed over time. But I'll take your patch, definitely. I'll put it on the SVN trunk and schedule it for OMPI 1.7.5 (it's too late for 1.7.4). Thank you! On Jan 7, 2014, at 4:18 PM, Tobias Burnus wrote: > Hello, > > I'd like to see the following patch to be included in Open MPI, which enabled > interface checking also with GCC's gfortran. > > While TYPE(*), DIMENSION(*) is already tested for, it cannot be used for > scalars (and "TYPE(*)" cannot be used with arrays). [Those were added in GCC > 4.8, which diagnoses the rank mismatch. Fortran 2015 (?) will add support for > both scalars and dimensions.] > > In GCC 4.9, gfortran joins other compilers by supporting a directive which > disables the argument check (type, kind, rank checking: TKR): NO_ARG_CHECK. > > The attached patch does so. The original version has been added 8 months ago > to > https://bitbucket.org/jsquyres/mpi3-fortran/commits/243ffae9f63ffc8fcdfdc604796ef290963ea1c4 > - but as it hasn't been merged to the Open MPI, I submit it with this email > (rediffed with some additional cases). > > I'd be delighted if the patch could be applied to the trunk - and possibly > even be backported to 1.7. (I think it also applies to 1.6 but I haven't > checked.) > > Tobias > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
