On Sep 14, 2015, at 12:40 AM, Gilles Gouaillardet wrote:
>
> that leads to a few questions :
> 1) should we handle this scenario (e.g. check config file) in mtt test itself
> ? (and how ? via MPIT ? )
The tests (sorta) tried to handle this.
I got some inspiration from Gilles' initial commit, a
Ralph,
the collective/op, collective/op_mpifh, collective/op_usempi,
group/group, onesided/c_lock_illegal and random/attr-error-code fails
because your contrib/platform/intel/bend/linux.conf contains the
following line
mpi_param_check = 0
and this is not handled correctly by ibm test suite.
Ah yes, that could be it. I wasn't looking at any .ini file to pull up those
settings -- I was looking at the MTT output (you can see what configure line
was used in the test run output). Perhaps Gilles is right: MTT gets random
garbage in the "already installed" case...? Sounds like a bug, b
Ralph,
according to mtt logs (click on the MPI Install button at the top left
corner), ompi was built in zero seconds ...
iirc, you do not build ompi under mtt, but you use the mtt "installed"
module
so my best bet is mtt logged some garbage since it has no way to figure out
how ompi was configure
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
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
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
e
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 versi
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
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
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 cre
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 conf
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
> 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 s
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 clea
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 u
16 matches
Mail list logo
