date:20150912

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Gilles Gouaillardet

Ralph,

at first glance, these errors look unrelated to PMIx.
I noticed a bunch of bind() failure.
based on your command line, I guess you are not running your job via a
batch manager,
and I would guess not all unix sockets are always cleaned up.
(or this is an old bug and you did not manually clean your nodes when it
was fixed)

the neighbor_allgather_self failure is discussed at
https://github.com/open-mpi/ompi/pull/790

I will have a look at the op related failure on Monday
(looks like a MPI conformance issue unrelated to PMIx)

Cheers,

Gilles

On Saturday, September 12, 2015, Ralph Castain  wrote:

> Hi folks
>
> I’ve closed all the holes I can find in the PMIx integration, and things
> look pretty good overall. There are a handful of failures still being seen
> - most of them involving what appear to be unrelated code. I’m not entirely
> sure I understand the source of the errors, and could really use some help
> to determine (a) if these are in any way related to PMIx, and if so (b) how.
>
> The errors from my MTT run are here:
> http://mtt.open-mpi.org/index.php?do_redir=2256
>
> Any help diagnosing these problems would be greatly appreciated
> Ralph
>
>

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Ralph Castain


> On Sep 11, 2015, at 10:00 PM, Gilles Gouaillardet 
>  wrote:
> 
> Ralph,
> 
> at first glance, these errors look unrelated to PMIx.
> I noticed a bunch of bind() failure.
> based on your command line, I guess you are not running your job via a batch 
> manager,
> and I would guess not all unix sockets are always cleaned up.

Yeah, the no-disconnect test was causing mpirun to segfault, which meant that 
the sockets weren’t cleaned up. So eventually I’d hit a case where they 
collided. Simply blowing away the session directory tree resolves the problem.

> (or this is an old bug and you did not manually clean your nodes when it was 
> fixed)
> 
> the neighbor_allgather_self failure is discussed at 
> https://github.com/open-mpi/ompi/pull/790 
> 
Ah, indeed - thanks!

> 
> I will have a look at the op related failure on Monday
> (looks like a MPI conformance issue unrelated to PMIx)

Again, thanks!

> 
> Cheers,
> 
> Gilles
> 
> On Saturday, September 12, 2015, Ralph Castain  > wrote:
> Hi folks
> 
> I’ve closed all the holes I can find in the PMIx integration, and things look 
> pretty good overall. There are a handful of failures still being seen - most 
> of them involving what appear to be unrelated code. I’m not entirely sure I 
> understand the source of the errors, and could really use some help to 
> determine (a) if these are in any way related to PMIx, and if so (b) how.
> 
> The errors from my MTT run are here:  
> http://mtt.open-mpi.org/index.php?do_redir=2256 
> 
> 
> Any help diagnosing these problems would be greatly appreciated
> Ralph
> 
> ___
> 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/2015/09/18015.php

Re: [OMPI devel] oshmem examples cannot be built

2015-09-12 Thread Jeff Squyres (jsquyres)

On Sep 11, 2015, at 9:00 PM, Ralph Castain  wrote:
> 
> FWIW: shemcc is just a symlink to mpicc, and I don’t see any -loshmem in that 
> —showme output

$ shmemcc --showme
gcc -I/home/jsquyres/bogus/include -pthread -Wl,-rpath 
-Wl,/home/jsquyres/bogus/lib -Wl,--enable-new-dtags -L/home/jsquyres/bogus/lib 
-loshmem -lmpi

The actual argv[0] of the executable should be determining which data file is 
used to populate the underlying argv.

Probably best to open a github issue on this and assign to the OSHMEM devs to 
figure out what is going on here...?


> 
>> On Sep 11, 2015, at 5:43 PM, Ralph Castain  wrote:
>> 
>> I typed “make” - the Makefile determines what to call. I suspect it isn’t 
>> calling the right thing
>> 
>> 
>>> On Sep 11, 2015, at 4:17 PM, Jeff Squyres (jsquyres)  
>>> wrote:
>>> 
>>> Shouldn't you be using shmemcc, not mpicc?
>>> 
>>> 
 On Sep 11, 2015, at 7:01 PM, Ralph Castain  wrote:
 
 On current master:
 
 03:57:56  (topic/pmix) /home/common/openmpi/foobar/examples$ make 
 ring_oshmem_c
 mpicc -gring_oshmem_c.c   -o ring_oshmem_c
 /tmp/ccfqcVje.o: In function `main':
 /home/common/openmpi/foobar/examples/ring_oshmem_c.c:20: undefined 
 reference to `start_pes'
 /home/common/openmpi/foobar/examples/ring_oshmem_c.c:21: undefined 
 reference to `_my_pe'
 /home/common/openmpi/foobar/examples/ring_oshmem_c.c:22: undefined 
 reference to `_num_pes'
 /home/common/openmpi/foobar/examples/ring_oshmem_c.c:32: undefined 
 reference to `shmem_int_put'
 /home/common/openmpi/foobar/examples/ring_oshmem_c.c:44: undefined 
 reference to `shmem_int_wait_until'
 /home/common/openmpi/foobar/examples/ring_oshmem_c.c:49: undefined 
 reference to `shmem_int_put'
 collect2: error: ld returned 1 exit status
 make: *** [ring_oshmem_c] Error 1
 03:58:51  (topic/pmix) /home/common/openmpi/foobar/examples$ mpicc --showme
 gcc -I/home/common/openmpi/build/foobar/include/openmpi 
 -I/home/common/openmpi/build/foobar/include/openmpi/opal/mca/hwloc/hwloc1110/hwloc/include
  
 -I/home/common/openmpi/build/foobar/include/openmpi/opal/mca/event/libevent2022/libevent
  
 -I/home/common/openmpi/build/foobar/include/openmpi/opal/mca/event/libevent2022/libevent/include
  -I/home/common/openmpi/build/foobar/include -pthread -Wl,-rpath 
 -Wl,/home/common/openmpi/build/foobar/lib -Wl,--enable-new-dtags 
 -L/home/common/openmpi/build/foobar/lib -lmpi
 03:59:12  (topic/pmix) /home/common/openmpi/foobar/examples$ 
 
 None of the oshmem examples can be built - all fail with the same error. 
 My configure:
 
 enable_orterun_prefix_by_default=yes
 enable_mpi_thread_multiple=no
 enable_mem_debug=no
 enable_mem_profile=no
 enable_debug_symbols=yes
 enable_binaries=yes
 enable_heterogeneous=no
 enable_picky=yes
 enable_debug=yes
 enable_shared=yes
 enable_static=no
 enable_memchecker=no
 enable_ipv6=no
 enable_mpi_fortran=yes
 enable_mpi_cxx=no
 enable_mpi_cxx_seek=no
 enable_cxx_exceptions=no
 enable_mpi_java=no
 enable_io_romio=no
 enable_contrib_no_build=libnbc
 with_memory_manager=no
 with_tm=no
 with_devel_headers=yes
 with_portals=no
 with_valgrind=no
 if [ -n "$SLURMHOME" ] ; then
  with_slurm=$SLURMHOME
  with_pmi=$SLURMHOME
 else
  with_slurm=no
 fi
 
 
 Ralph
 
 ___
 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/2015/09/18010.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/2015/09/18011.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/2015/09/18014.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] Remaining MTT errors

2015-09-12 Thread Jeff Squyres (jsquyres)

I notice that your configure line in the MTT tests is this:

CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron -xprefetch 
-xprefetch_level=2
-xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
CFLAGS="-xtarget=opteron
-xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
-xarch=amd64a -xO5"
--with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
-xvector=simd,lib
-xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" CXXFLAGS="-xtarget=opteron 
-xprefetch
-xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a 
-xO5"
--with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
-xvector=simd,lib -stackvar
-xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch -xprefetch_level=2 
-xvector=simd,lib
-stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
-xprefetch -xprefetch_level=2
-xvector=simd,lib -stackvar -xarch=amd64a -xO5" FCFLAGS="-xtarget=opteron 
-xprefetch
-xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 

What compiler suite is that?  Is -xO5 really safe to use?



> On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
> 
> Hi folks
> 
> I’ve closed all the holes I can find in the PMIx integration, and things look 
> pretty good overall. There are a handful of failures still being seen - most 
> of them involving what appear to be unrelated code. I’m not entirely sure I 
> understand the source of the errors, and could really use some help to 
> determine (a) if these are in any way related to PMIx, and if so (b) how.
> 
> The errors from my MTT run are here:  
> http://mtt.open-mpi.org/index.php?do_redir=2256
> 
> Any help diagnosing these problems would be greatly appreciated
> Ralph
> 
> ___
> 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/2015/09/18013.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] Remaining MTT errors

2015-09-12 Thread Ralph Castain

Note that I didn’t set any of those flags outside of the CC and friends - they 
are being set by our MTT test configure itself. The compiler is just gcc 4.8.3, 
and I suspect O5 is asking a bit from it.


> On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
> I notice that your configure line in the MTT tests is this:
> 
> CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
> -xprefetch -xprefetch_level=2
> -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
> CFLAGS="-xtarget=opteron
> -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
> -xarch=amd64a -xO5"
> --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
> -xvector=simd,lib
> -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" CXXFLAGS="-xtarget=opteron 
> -xprefetch
> -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
> -xarch=amd64a -xO5"
> --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
> -xvector=simd,lib -stackvar
> -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch -xprefetch_level=2 
> -xvector=simd,lib
> -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
> -xprefetch -xprefetch_level=2
> -xvector=simd,lib -stackvar -xarch=amd64a -xO5" FCFLAGS="-xtarget=opteron 
> -xprefetch
> -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
> 
> What compiler suite is that?  Is -xO5 really safe to use?
> 
> 
> 
>> On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
>> 
>> Hi folks
>> 
>> I’ve closed all the holes I can find in the PMIx integration, and things 
>> look pretty good overall. There are a handful of failures still being seen - 
>> most of them involving what appear to be unrelated code. I’m not entirely 
>> sure I understand the source of the errors, and could really use some help 
>> to determine (a) if these are in any way related to PMIx, and if so (b) how.
>> 
>> The errors from my MTT run are here:  
>> http://mtt.open-mpi.org/index.php?do_redir=2256
>> 
>> Any help diagnosing these problems would be greatly appreciated
>> Ralph
>> 
>> ___
>> 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/2015/09/18013.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/2015/09/18018.php

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Ralph Castain

I searched around, and I can’t for the life of me see where all that cruft is 
coming from. Any suggestions?

Here is the top of the config.log from that build:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by ompi-ibm configure 10.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure CC=mpicc CXX=mpic++ F77=mpif77

## - ##
## Platform. ##
## - ##

hostname = bend001
uname -m = x86_64
uname -r = 3.10.0-229.7.2.el7.x86_64
uname -s = Linux
uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015

Do you want to see the log itself? I’m at a loss as to why it would add that 
stuff.


> On Sep 12, 2015, at 7:38 AM, Ralph Castain  wrote:
> 
> Note that I didn’t set any of those flags outside of the CC and friends - 
> they are being set by our MTT test configure itself. The compiler is just gcc 
> 4.8.3, and I suspect O5 is asking a bit from it.
> 
> 
>> On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres)  
>> wrote:
>> 
>> I notice that your configure line in the MTT tests is this:
>> 
>> CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
>> -xprefetch -xprefetch_level=2
>> -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
>> CFLAGS="-xtarget=opteron
>> -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
>> -xarch=amd64a -xO5"
>> --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>> -xvector=simd,lib
>> -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" CXXFLAGS="-xtarget=opteron 
>> -xprefetch
>> -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
>> -xarch=amd64a -xO5"
>> --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>> -xvector=simd,lib -stackvar
>> -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch -xprefetch_level=2 
>> -xvector=simd,lib
>> -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
>> -xprefetch -xprefetch_level=2
>> -xvector=simd,lib -stackvar -xarch=amd64a -xO5" FCFLAGS="-xtarget=opteron 
>> -xprefetch
>> -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
>> 
>> What compiler suite is that?  Is -xO5 really safe to use?
>> 
>> 
>> 
>>> On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
>>> 
>>> Hi folks
>>> 
>>> I’ve closed all the holes I can find in the PMIx integration, and things 
>>> look pretty good overall. There are a handful of failures still being seen 
>>> - most of them involving what appear to be unrelated code. I’m not entirely 
>>> sure I understand the source of the errors, and could really use some help 
>>> to determine (a) if these are in any way related to PMIx, and if so (b) how.
>>> 
>>> The errors from my MTT run are here:  
>>> http://mtt.open-mpi.org/index.php?do_redir=2256
>>> 
>>> Any help diagnosing these problems would be greatly appreciated
>>> Ralph
>>> 
>>> ___
>>> 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/2015/09/18013.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/2015/09/18018.php
>

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Jeff Squyres (jsquyres)

Sorry; I should have been clear -- the configure line I was specifying was from 
building Open MPI itself.

I.e., it's your MTT infrastructure/ini file that is adding those flags.

The config.log you show below looks like it is for one of the test suites 
(i.e., it's using the wrappers, which could not have been done for the main 
OMPI build itself).


> On Sep 12, 2015, at 10:59 AM, Ralph Castain  wrote:
> 
> I searched around, and I can’t for the life of me see where all that cruft is 
> coming from. Any suggestions?
> 
> Here is the top of the config.log from that build:
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> It was created by ompi-ibm configure 10.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
> 
>  $ ./configure CC=mpicc CXX=mpic++ F77=mpif77
> 
> ## - ##
> ## Platform. ##
> ## - ##
> 
> hostname = bend001
> uname -m = x86_64
> uname -r = 3.10.0-229.7.2.el7.x86_64
> uname -s = Linux
> uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015
> 
> Do you want to see the log itself? I’m at a loss as to why it would add that 
> stuff.
> 
> 
>> On Sep 12, 2015, at 7:38 AM, Ralph Castain  wrote:
>> 
>> Note that I didn’t set any of those flags outside of the CC and friends - 
>> they are being set by our MTT test configure itself. The compiler is just 
>> gcc 4.8.3, and I suspect O5 is asking a bit from it.
>> 
>> 
>>> On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres)  
>>> wrote:
>>> 
>>> I notice that your configure line in the MTT tests is this:
>>> 
>>> CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
>>> -xprefetch -xprefetch_level=2
>>> -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
>>> CFLAGS="-xtarget=opteron
>>> -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
>>> -xarch=amd64a -xO5"
>>> --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>>> -xvector=simd,lib
>>> -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" CXXFLAGS="-xtarget=opteron 
>>> -xprefetch
>>> -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
>>> -xarch=amd64a -xO5"
>>> --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>>> -xvector=simd,lib -stackvar
>>> -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch -xprefetch_level=2 
>>> -xvector=simd,lib
>>> -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
>>> -xprefetch -xprefetch_level=2
>>> -xvector=simd,lib -stackvar -xarch=amd64a -xO5" FCFLAGS="-xtarget=opteron 
>>> -xprefetch
>>> -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
>>> 
>>> What compiler suite is that?  Is -xO5 really safe to use?
>>> 
>>> 
>>> 
 On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
 
 Hi folks
 
 I’ve closed all the holes I can find in the PMIx integration, and things 
 look pretty good overall. There are a handful of failures still being seen 
 - most of them involving what appear to be unrelated code. I’m not 
 entirely sure I understand the source of the errors, and could really use 
 some help to determine (a) if these are in any way related to PMIx, and if 
 so (b) how.
 
 The errors from my MTT run are here:  
 http://mtt.open-mpi.org/index.php?do_redir=2256
 
 Any help diagnosing these problems would be greatly appreciated
 Ralph
 
 ___
 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/2015/09/18013.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/2015/09/18018.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/2015/09/18020.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] Remaining MTT errors

2015-09-12 Thread Jeff Squyres (jsquyres)

FWIW, I have various versions of gcc from 4.4.7 to 5.2 -- I don't have 4.8.3, 
but I do have 4.8.1, and I can't get it to recognize the -xO5 switch that 
you're using:

-
$ gcc --version
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -xO5 hello.c -o hello
gcc: error: language O5 not recognized
gcc: error: language O5 not recognized
-


> On Sep 12, 2015, at 11:09 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
> Sorry; I should have been clear -- the configure line I was specifying was 
> from building Open MPI itself.
> 
> I.e., it's your MTT infrastructure/ini file that is adding those flags.
> 
> The config.log you show below looks like it is for one of the test suites 
> (i.e., it's using the wrappers, which could not have been done for the main 
> OMPI build itself).
> 
> 
>> On Sep 12, 2015, at 10:59 AM, Ralph Castain  wrote:
>> 
>> I searched around, and I can’t for the life of me see where all that cruft 
>> is coming from. Any suggestions?
>> 
>> Here is the top of the config.log from that build:
>> 
>> This file contains any messages produced by compilers while
>> running configure, to aid debugging if configure makes a mistake.
>> 
>> It was created by ompi-ibm configure 10.0, which was
>> generated by GNU Autoconf 2.69.  Invocation command line was
>> 
>> $ ./configure CC=mpicc CXX=mpic++ F77=mpif77
>> 
>> ## - ##
>> ## Platform. ##
>> ## - ##
>> 
>> hostname = bend001
>> uname -m = x86_64
>> uname -r = 3.10.0-229.7.2.el7.x86_64
>> uname -s = Linux
>> uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015
>> 
>> Do you want to see the log itself? I’m at a loss as to why it would add that 
>> stuff.
>> 
>> 
>>> On Sep 12, 2015, at 7:38 AM, Ralph Castain  wrote:
>>> 
>>> Note that I didn’t set any of those flags outside of the CC and friends - 
>>> they are being set by our MTT test configure itself. The compiler is just 
>>> gcc 4.8.3, and I suspect O5 is asking a bit from it.
>>> 
>>> 
 On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres)  
 wrote:
 
 I notice that your configure line in the MTT tests is this:
 
 CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
 -xprefetch -xprefetch_level=2
 -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
 CFLAGS="-xtarget=opteron
 -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes 
 -xbuiltin=%all -xarch=amd64a -xO5"
 --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
 -xvector=simd,lib
 -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" CXXFLAGS="-xtarget=opteron 
 -xprefetch
 -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
 -xarch=amd64a -xO5"
 --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
 -xvector=simd,lib -stackvar
 -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch -xprefetch_level=2 
 -xvector=simd,lib
 -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
 -xprefetch -xprefetch_level=2
 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" FCFLAGS="-xtarget=opteron 
 -xprefetch
 -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
 
 What compiler suite is that?  Is -xO5 really safe to use?
 
 
 
> On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
> 
> Hi folks
> 
> I’ve closed all the holes I can find in the PMIx integration, and things 
> look pretty good overall. There are a handful of failures still being 
> seen - most of them involving what appear to be unrelated code. I’m not 
> entirely sure I understand the source of the errors, and could really use 
> some help to determine (a) if these are in any way related to PMIx, and 
> if so (b) how.
> 
> The errors from my MTT run are here:  
> http://mtt.open-mpi.org/index.php?do_redir=2256
> 
> Any help diagnosing these problems would be greatly appreciated
> Ralph
> 
> ___
> 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/2015/09/18013.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/2015/09/18018.php
>>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: h

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Ralph Castain

I’ve attached my .ini file - can you please tell me *where* these things are 
being set?? I haven’t consciously done anything about configure in these tests.



bend-local.ini
Description: Binary data

> On Sep 12, 2015, at 8:14 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
> FWIW, I have various versions of gcc from 4.4.7 to 5.2 -- I don't have 4.8.3, 
> but I do have 4.8.1, and I can't get it to recognize the -xO5 switch that 
> you're using:
> 
> -
> $ gcc --version
> gcc (GCC) 4.8.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ gcc -xO5 hello.c -o hello
> gcc: error: language O5 not recognized
> gcc: error: language O5 not recognized
> -
> 
> 
>> On Sep 12, 2015, at 11:09 AM, Jeff Squyres (jsquyres)  
>> wrote:
>> 
>> Sorry; I should have been clear -- the configure line I was specifying was 
>> from building Open MPI itself.
>> 
>> I.e., it's your MTT infrastructure/ini file that is adding those flags.
>> 
>> The config.log you show below looks like it is for one of the test suites 
>> (i.e., it's using the wrappers, which could not have been done for the main 
>> OMPI build itself).
>> 
>> 
>>> On Sep 12, 2015, at 10:59 AM, Ralph Castain  wrote:
>>> 
>>> I searched around, and I can’t for the life of me see where all that cruft 
>>> is coming from. Any suggestions?
>>> 
>>> Here is the top of the config.log from that build:
>>> 
>>> This file contains any messages produced by compilers while
>>> running configure, to aid debugging if configure makes a mistake.
>>> 
>>> It was created by ompi-ibm configure 10.0, which was
>>> generated by GNU Autoconf 2.69.  Invocation command line was
>>> 
>>> $ ./configure CC=mpicc CXX=mpic++ F77=mpif77
>>> 
>>> ## - ##
>>> ## Platform. ##
>>> ## - ##
>>> 
>>> hostname = bend001
>>> uname -m = x86_64
>>> uname -r = 3.10.0-229.7.2.el7.x86_64
>>> uname -s = Linux
>>> uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015
>>> 
>>> Do you want to see the log itself? I’m at a loss as to why it would add 
>>> that stuff.
>>> 
>>> 
 On Sep 12, 2015, at 7:38 AM, Ralph Castain  wrote:
 
 Note that I didn’t set any of those flags outside of the CC and friends - 
 they are being set by our MTT test configure itself. The compiler is just 
 gcc 4.8.3, and I suspect O5 is asking a bit from it.
 
 
> On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
> I notice that your configure line in the MTT tests is this:
> 
> CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
> -xprefetch -xprefetch_level=2
> -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
> CFLAGS="-xtarget=opteron
> -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes 
> -xbuiltin=%all -xarch=amd64a -xO5"
> --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
> -xvector=simd,lib
> -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
> CXXFLAGS="-xtarget=opteron -xprefetch
> -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
> -xarch=amd64a -xO5"
> --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
> -xvector=simd,lib -stackvar
> -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch 
> -xprefetch_level=2 -xvector=simd,lib
> -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
> -xprefetch -xprefetch_level=2
> -xvector=simd,lib -stackvar -xarch=amd64a -xO5" FCFLAGS="-xtarget=opteron 
> -xprefetch
> -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
> 
> What compiler suite is that?  Is -xO5 really safe to use?
> 
> 
> 
>> On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
>> 
>> Hi folks
>> 
>> I’ve closed all the holes I can find in the PMIx integration, and things 
>> look pretty good overall. There are a handful of failures still being 
>> seen - most of them involving what appear to be unrelated code. I’m not 
>> entirely sure I understand the source of the errors, and could really 
>> use some help to determine (a) if these are in any way related to PMIx, 
>> and if so (b) how.
>> 
>> The errors from my MTT run are here:  
>> http://mtt.open-mpi.org/index.php?do_redir=2256
>> 
>> Any help diagnosing these problems would be greatly appreciated
>> Ralph
>> 
>> ___
>> 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/2015/09/18013.php
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doin

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Ralph Castain

As for building OMPI, here is the configure I used:

08:18:39  (topic/pmix) /home/common/openmpi/foobar$ cat 
contrib/platform/intel/bend/linux
enable_orterun_prefix_by_default=yes
enable_mpi_thread_multiple=no
enable_mem_debug=no
enable_mem_profile=no
enable_debug_symbols=yes
enable_binaries=yes
enable_heterogeneous=no
enable_picky=yes
enable_debug=yes
enable_shared=yes
enable_static=no
enable_memchecker=no
enable_ipv6=no
enable_mpi_fortran=yes
enable_mpi_cxx=no
enable_mpi_cxx_seek=no
enable_cxx_exceptions=no
enable_mpi_java=no
enable_io_romio=no
enable_contrib_no_build=libnbc
with_memory_manager=no
with_tm=no
with_devel_headers=yes
with_portals=no
with_valgrind=no
if [ -n "$SLURMHOME" ] ; then
with_slurm=$SLURMHOME
with_pmi=$SLURMHOME
else
with_slurm=no
fi

So where is all that cruft coming from??


> On Sep 12, 2015, at 8:17 AM, Ralph Castain  wrote:
> 
> I’ve attached my .ini file - can you please tell me *where* these things are 
> being set?? I haven’t consciously done anything about configure in these 
> tests.
> 
> 
>> On Sep 12, 2015, at 8:14 AM, Jeff Squyres (jsquyres)  
>> wrote:
>> 
>> FWIW, I have various versions of gcc from 4.4.7 to 5.2 -- I don't have 
>> 4.8.3, but I do have 4.8.1, and I can't get it to recognize the -xO5 switch 
>> that you're using:
>> 
>> -
>> $ gcc --version
>> gcc (GCC) 4.8.1
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> 
>> $ gcc -xO5 hello.c -o hello
>> gcc: error: language O5 not recognized
>> gcc: error: language O5 not recognized
>> -
>> 
>> 
>>> On Sep 12, 2015, at 11:09 AM, Jeff Squyres (jsquyres)  
>>> wrote:
>>> 
>>> Sorry; I should have been clear -- the configure line I was specifying was 
>>> from building Open MPI itself.
>>> 
>>> I.e., it's your MTT infrastructure/ini file that is adding those flags.
>>> 
>>> The config.log you show below looks like it is for one of the test suites 
>>> (i.e., it's using the wrappers, which could not have been done for the main 
>>> OMPI build itself).
>>> 
>>> 
 On Sep 12, 2015, at 10:59 AM, Ralph Castain  wrote:
 
 I searched around, and I can’t for the life of me see where all that cruft 
 is coming from. Any suggestions?
 
 Here is the top of the config.log from that build:
 
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
 It was created by ompi-ibm configure 10.0, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
 $ ./configure CC=mpicc CXX=mpic++ F77=mpif77
 
 ## - ##
 ## Platform. ##
 ## - ##
 
 hostname = bend001
 uname -m = x86_64
 uname -r = 3.10.0-229.7.2.el7.x86_64
 uname -s = Linux
 uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015
 
 Do you want to see the log itself? I’m at a loss as to why it would add 
 that stuff.
 
 
> On Sep 12, 2015, at 7:38 AM, Ralph Castain  wrote:
> 
> Note that I didn’t set any of those flags outside of the CC and friends - 
> they are being set by our MTT test configure itself. The compiler is just 
> gcc 4.8.3, and I suspect O5 is asking a bit from it.
> 
> 
>> On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres) 
>>  wrote:
>> 
>> I notice that your configure line in the MTT tests is this:
>> 
>> CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
>> -xprefetch -xprefetch_level=2
>> -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
>> CFLAGS="-xtarget=opteron
>> -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes 
>> -xbuiltin=%all -xarch=amd64a -xO5"
>> --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>> -xvector=simd,lib
>> -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
>> CXXFLAGS="-xtarget=opteron -xprefetch
>> -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
>> -xarch=amd64a -xO5"
>> --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>> -xvector=simd,lib -stackvar
>> -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch 
>> -xprefetch_level=2 -xvector=simd,lib
>> -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
>> -xprefetch -xprefetch_level=2
>> -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
>> FCFLAGS="-xtarget=opteron -xprefetch
>> -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
>> 
>> What compiler suite is that?  Is -xO5 really safe to use?
>> 
>> 
>> 
>>> On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
>>> 
>>> Hi folks
>>> 
>>> I’ve closed all the holes I can find in the PMIx integration, and 
>>> things look pretty good ove

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Paul Hargrove

In case it helps: those "-x..." switches and "%all" syntax are sure signs
of the Solaris Studio compilers.

$ suncc -xtarget=opteron -xprefetch -xprefetch_level=2 -xvector=simd,lib
-xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5 hello.c
cc: Warning: -xarch=amd64a is deprecated, use -m64 -xarch=sse2a instead

-Paul

On Sat, Sep 12, 2015 at 8:14 AM, Jeff Squyres (jsquyres)  wrote:

> FWIW, I have various versions of gcc from 4.4.7 to 5.2 -- I don't have
> 4.8.3, but I do have 4.8.1, and I can't get it to recognize the -xO5 switch
> that you're using:
>
> -
> $ gcc --version
> gcc (GCC) 4.8.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ gcc -xO5 hello.c -o hello
> gcc: error: language O5 not recognized
> gcc: error: language O5 not recognized
> -
>
>
> > On Sep 12, 2015, at 11:09 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> >
> > Sorry; I should have been clear -- the configure line I was specifying
> was from building Open MPI itself.
> >
> > I.e., it's your MTT infrastructure/ini file that is adding those flags.
> >
> > The config.log you show below looks like it is for one of the test
> suites (i.e., it's using the wrappers, which could not have been done for
> the main OMPI build itself).
> >
> >
> >> On Sep 12, 2015, at 10:59 AM, Ralph Castain  wrote:
> >>
> >> I searched around, and I can’t for the life of me see where all that
> cruft is coming from. Any suggestions?
> >>
> >> Here is the top of the config.log from that build:
> >>
> >> This file contains any messages produced by compilers while
> >> running configure, to aid debugging if configure makes a mistake.
> >>
> >> It was created by ompi-ibm configure 10.0, which was
> >> generated by GNU Autoconf 2.69.  Invocation command line was
> >>
> >> $ ./configure CC=mpicc CXX=mpic++ F77=mpif77
> >>
> >> ## - ##
> >> ## Platform. ##
> >> ## - ##
> >>
> >> hostname = bend001
> >> uname -m = x86_64
> >> uname -r = 3.10.0-229.7.2.el7.x86_64
> >> uname -s = Linux
> >> uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015
> >>
> >> Do you want to see the log itself? I’m at a loss as to why it would add
> that stuff.
> >>
> >>
> >>> On Sep 12, 2015, at 7:38 AM, Ralph Castain  wrote:
> >>>
> >>> Note that I didn’t set any of those flags outside of the CC and
> friends - they are being set by our MTT test configure itself. The compiler
> is just gcc 4.8.3, and I suspect O5 is asking a bit from it.
> >>>
> >>>
>  On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> 
>  I notice that your configure line in the MTT tests is this:
> 
>  CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron
> -xprefetch -xprefetch_level=2
>  -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5"
> CFLAGS="-xtarget=opteron
>  -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes
> -xbuiltin=%all -xarch=amd64a -xO5"
>  --with-wrapper-cxxflags="-xtarget=opteron -xprefetch
> -xprefetch_level=2 -xvector=simd,lib
>  -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5"
> CXXFLAGS="-xtarget=opteron -xprefetch
>  -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all
> -xarch=amd64a -xO5"
>  --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2
> -xvector=simd,lib -stackvar
>  -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch
> -xprefetch_level=2 -xvector=simd,lib
>  -stackvar -xarch=amd64a -xO5"
> --with-wrapper-fcflags="-xtarget=opteron -xprefetch -xprefetch_level=2
>  -xvector=simd,lib -stackvar -xarch=amd64a -xO5"
> FCFLAGS="-xtarget=opteron -xprefetch
>  -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5"
> 
>  What compiler suite is that?  Is -xO5 really safe to use?
> 
> 
> 
> > On Sep 11, 2015, at 8:51 PM, Ralph Castain  wrote:
> >
> > Hi folks
> >
> > I’ve closed all the holes I can find in the PMIx integration, and
> things look pretty good overall. There are a handful of failures still
> being seen - most of them involving what appear to be unrelated code. I’m
> not entirely sure I understand the source of the errors, and could really
> use some help to determine (a) if these are in any way related to PMIx, and
> if so (b) how.
> >
> > The errors from my MTT run are here:
> http://mtt.open-mpi.org/index.php?do_redir=2256
> >
> > Any help diagnosing these problems would be greatly appreciated
> > Ralph
> >
> > ___
> > 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/2015/09/18013.php
> 
> 
>  --
>  Jeff Squyres
>  jsquy...@cisco.com
>  For

Re: [OMPI devel] Remaining MTT errors

2015-09-12 Thread Ralph Castain

I don’t think Jeff is pulling up the right configure line. I don’t have Solaris 
compilers on this system, I can’t find anything remotely resembling the 
configure line he is quoting, etc.

I wonder if MTT is confused because I am using the “as provided” option for 
OMPI - i.e., MTT isn’t building OMPI and just uses my “already installed” build?

Or else Jeff is just clicking on the wrong button :-)

Either way, I think this is just a red herring


> On Sep 12, 2015, at 8:27 AM, Paul Hargrove  wrote:
> 
> In case it helps: those "-x..." switches and "%all" syntax are sure signs of 
> the Solaris Studio compilers.
> 
> $ suncc -xtarget=opteron -xprefetch -xprefetch_level=2 -xvector=simd,lib 
> -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5 hello.c
> cc: Warning: -xarch=amd64a is deprecated, use -m64 -xarch=sse2a instead
> 
> -Paul
> 
> On Sat, Sep 12, 2015 at 8:14 AM, Jeff Squyres (jsquyres)  > wrote:
> FWIW, I have various versions of gcc from 4.4.7 to 5.2 -- I don't have 4.8.3, 
> but I do have 4.8.1, and I can't get it to recognize the -xO5 switch that 
> you're using:
> 
> -
> $ gcc --version
> gcc (GCC) 4.8.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ gcc -xO5 hello.c -o hello
> gcc: error: language O5 not recognized
> gcc: error: language O5 not recognized
> -
> 
> 
> > On Sep 12, 2015, at 11:09 AM, Jeff Squyres (jsquyres)  > > wrote:
> >
> > Sorry; I should have been clear -- the configure line I was specifying was 
> > from building Open MPI itself.
> >
> > I.e., it's your MTT infrastructure/ini file that is adding those flags.
> >
> > The config.log you show below looks like it is for one of the test suites 
> > (i.e., it's using the wrappers, which could not have been done for the main 
> > OMPI build itself).
> >
> >
> >> On Sep 12, 2015, at 10:59 AM, Ralph Castain  >> > wrote:
> >>
> >> I searched around, and I can’t for the life of me see where all that cruft 
> >> is coming from. Any suggestions?
> >>
> >> Here is the top of the config.log from that build:
> >>
> >> This file contains any messages produced by compilers while
> >> running configure, to aid debugging if configure makes a mistake.
> >>
> >> It was created by ompi-ibm configure 10.0, which was
> >> generated by GNU Autoconf 2.69.  Invocation command line was
> >>
> >> $ ./configure CC=mpicc CXX=mpic++ F77=mpif77
> >>
> >> ## - ##
> >> ## Platform. ##
> >> ## - ##
> >>
> >> hostname = bend001
> >> uname -m = x86_64
> >> uname -r = 3.10.0-229.7.2.el7.x86_64
> >> uname -s = Linux
> >> uname -v = #1 SMP Tue Jun 23 22:06:11 UTC 2015
> >>
> >> Do you want to see the log itself? I’m at a loss as to why it would add 
> >> that stuff.
> >>
> >>
> >>> On Sep 12, 2015, at 7:38 AM, Ralph Castain  >>> > wrote:
> >>>
> >>> Note that I didn’t set any of those flags outside of the CC and friends - 
> >>> they are being set by our MTT test configure itself. The compiler is just 
> >>> gcc 4.8.3, and I suspect O5 is asking a bit from it.
> >>>
> >>>
>  On Sep 12, 2015, at 6:08 AM, Jeff Squyres (jsquyres)   > wrote:
> 
>  I notice that your configure line in the MTT tests is this:
> 
>  CC=cc CXX=CC FC=f90 F77=f77 --with-wrapper-cflags="-xtarget=opteron 
>  -xprefetch -xprefetch_level=2
>  -xvector=simd,lib -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
>  CFLAGS="-xtarget=opteron
>  -xprefetch -xprefetch_level=2 -xvector=simd,lib -xdepend=yes 
>  -xbuiltin=%all -xarch=amd64a -xO5"
>  --with-wrapper-cxxflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>  -xvector=simd,lib
>  -xdepend=yes -xbuiltin=%all -xarch=amd64a -xO5" 
>  CXXFLAGS="-xtarget=opteron -xprefetch
>  -xprefetch_level=2 -xvector=simd,lib -xdepend=yes -xbuiltin=%all 
>  -xarch=amd64a -xO5"
>  --with-wrapper-fflags="-xtarget=opteron -xprefetch -xprefetch_level=2 
>  -xvector=simd,lib -stackvar
>  -xarch=amd64a -xO5" FFLAGS="-xtarget=opteron -xprefetch 
>  -xprefetch_level=2 -xvector=simd,lib
>  -stackvar -xarch=amd64a -xO5" --with-wrapper-fcflags="-xtarget=opteron 
>  -xprefetch -xprefetch_level=2
>  -xvector=simd,lib -stackvar -xarch=amd64a -xO5" 
>  FCFLAGS="-xtarget=opteron -xprefetch
>  -xprefetch_level=2 -xvector=simd,lib -stackvar -xarch=amd64a -xO5"
> 
>  What compiler suite is that?  Is -xO5 really safe to use?
> 
> 
> 
> > On Sep 11, 2015, at 8:51 PM, Ralph Castain  > > wrote:
> >
> > Hi folks
> >
> > I’ve closed all the holes I can find in the PMIx integration, and 
> > things look pretty good overall. There are a handful of failures still 
> > being seen - most of them

Re: [OMPI devel] oshmem examples cannot be built

2015-09-12 Thread Paul Hargrove

Another FYI.
In my Aug 26 build of master (openmpi-dev-2371-gea935df.tar.bz2) running
"make" in the examples directory *did* use shmemcc:

make[2]: Entering directory
`/home/phargrov/OMPI/openmpi-master-linux-x86_64-ss12u2/BLD/examples'
shmemcc -g ring_oshmem_c.c -o ring_oshmem

So, something has changed if mpicc is being used today.

-Paul

On Sat, Sep 12, 2015 at 5:58 AM, Jeff Squyres (jsquyres)  wrote:

> On Sep 11, 2015, at 9:00 PM, Ralph Castain  wrote:
> >
> > FWIW: shemcc is just a symlink to mpicc, and I don’t see any -loshmem in
> that —showme output
>
> $ shmemcc --showme
> gcc -I/home/jsquyres/bogus/include -pthread -Wl,-rpath
> -Wl,/home/jsquyres/bogus/lib -Wl,--enable-new-dtags
> -L/home/jsquyres/bogus/lib -loshmem -lmpi
>
> The actual argv[0] of the executable should be determining which data file
> is used to populate the underlying argv.
>
> Probably best to open a github issue on this and assign to the OSHMEM devs
> to figure out what is going on here...?
>
>
> >
> >> On Sep 11, 2015, at 5:43 PM, Ralph Castain  wrote:
> >>
> >> I typed “make” - the Makefile determines what to call. I suspect it
> isn’t calling the right thing
> >>
> >>
> >>> On Sep 11, 2015, at 4:17 PM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> >>>
> >>> Shouldn't you be using shmemcc, not mpicc?
> >>>
> >>>
>  On Sep 11, 2015, at 7:01 PM, Ralph Castain  wrote:
> 
>  On current master:
> 
>  03:57:56  (topic/pmix) /home/common/openmpi/foobar/examples$ make
> ring_oshmem_c
>  mpicc -gring_oshmem_c.c   -o ring_oshmem_c
>  /tmp/ccfqcVje.o: In function `main':
>  /home/common/openmpi/foobar/examples/ring_oshmem_c.c:20: undefined
> reference to `start_pes'
>  /home/common/openmpi/foobar/examples/ring_oshmem_c.c:21: undefined
> reference to `_my_pe'
>  /home/common/openmpi/foobar/examples/ring_oshmem_c.c:22: undefined
> reference to `_num_pes'
>  /home/common/openmpi/foobar/examples/ring_oshmem_c.c:32: undefined
> reference to `shmem_int_put'
>  /home/common/openmpi/foobar/examples/ring_oshmem_c.c:44: undefined
> reference to `shmem_int_wait_until'
>  /home/common/openmpi/foobar/examples/ring_oshmem_c.c:49: undefined
> reference to `shmem_int_put'
>  collect2: error: ld returned 1 exit status
>  make: *** [ring_oshmem_c] Error 1
>  03:58:51  (topic/pmix) /home/common/openmpi/foobar/examples$ mpicc
> --showme
>  gcc -I/home/common/openmpi/build/foobar/include/openmpi
> -I/home/common/openmpi/build/foobar/include/openmpi/opal/mca/hwloc/hwloc1110/hwloc/include
> -I/home/common/openmpi/build/foobar/include/openmpi/opal/mca/event/libevent2022/libevent
> -I/home/common/openmpi/build/foobar/include/openmpi/opal/mca/event/libevent2022/libevent/include
> -I/home/common/openmpi/build/foobar/include -pthread -Wl,-rpath
> -Wl,/home/common/openmpi/build/foobar/lib -Wl,--enable-new-dtags
> -L/home/common/openmpi/build/foobar/lib -lmpi
>  03:59:12  (topic/pmix) /home/common/openmpi/foobar/examples$
> 
>  None of the oshmem examples can be built - all fail with the same
> error. My configure:
> 
>  enable_orterun_prefix_by_default=yes
>  enable_mpi_thread_multiple=no
>  enable_mem_debug=no
>  enable_mem_profile=no
>  enable_debug_symbols=yes
>  enable_binaries=yes
>  enable_heterogeneous=no
>  enable_picky=yes
>  enable_debug=yes
>  enable_shared=yes
>  enable_static=no
>  enable_memchecker=no
>  enable_ipv6=no
>  enable_mpi_fortran=yes
>  enable_mpi_cxx=no
>  enable_mpi_cxx_seek=no
>  enable_cxx_exceptions=no
>  enable_mpi_java=no
>  enable_io_romio=no
>  enable_contrib_no_build=libnbc
>  with_memory_manager=no
>  with_tm=no
>  with_devel_headers=yes
>  with_portals=no
>  with_valgrind=no
>  if [ -n "$SLURMHOME" ] ; then
>   with_slurm=$SLURMHOME
>   with_pmi=$SLURMHOME
>  else
>   with_slurm=no
>  fi
> 
> 
>  Ralph
> 
>  ___
>  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/2015/09/18010.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/2015/09/18011.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/2015/09/18014.php
>
>
> --
> Jeff Squyres
> js

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] oshmem examples cannot be built

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] Remaining MTT errors

Re: [OMPI devel] oshmem examples cannot be built

13 matches

Site Navigation

Mail list logo

Footer information