Ah, I see that my problems on MacOS 10.4 are already a moot point, as my
"option (c)" has already been implemented.
From README in 1.5 branch:
- OS X (10.5, 10.6), 32 and 64 bit (x86_64), with gcc and Absoft
compilers (*)
and from trunk:
- OS X (10.5, 10.6, 10.7), 32 and 64 bit (x86_6
As a point for discussion, I am going to offer a simple solution:
c) Ignore this for 1.5.5 and raise the minimum MacOS version from 10.4
to 10.5 for ompi 1.6.x and 1.7.x
Any strong opinions?
-Paul
On 2/15/2012 10:29 AM, Paul H. Hargrove wrote:
I wanted to note that MacOS 10.4 on *X86* has th
Dmitri,
Since I have not seen any error like this from gcc, pgi, pathcc, xlc,
icc, open64 or suncc, I am pretty sure the problem is Clang-specific
even if not a true "bug" in Clang.
I just test everything I can get my hands on and report what I find.
If there is not a simple fix for this then
Thanks, Ralph.
Your commit missed the nightly tarball, but the configure logic to
exclude the rank_file component was in there.
So, I dropped the new libevent2013_module.c into tonight's tarball
(1.7a1r25937).
My build configured --without-hwloc now PASSes "make all install check
clean".
And
Thanks Paul. I modified the patch a bit to silence some warnings, but added
it to the trunk.
On Wed, Feb 15, 2012 at 2:17 PM, Paul H. Hargrove wrote:
> The following 1-line change resolves the problem for me, and I see no
> potential down-side to it:
>
> --- openmpi-1.7a1r25927/opal/mca/**event/
Testing a trunk tarball (1.7a1r25927) I am seeing an opal_path_nfs
failure from "make check":
Failure : Mismatch: input "/opt/cluster", expected:0 got:1
SUPPORT: OMPI Test failed: opal_path_nfs() (1 of 20 failed)
FAIL: opal_path_nfs
The "mount" command reports /opt/cluster as "nfs4" which app
The following 1-line change resolves the problem for me, and I see no
potential down-side to it:
---
openmpi-1.7a1r25927/opal/mca/event/libevent2013/libevent2013_module.c~
2012-02-15 14:11:22.274734667 -0800
+++
openmpi-1.7a1r25927/opal/mca/event/libevent2013/libevent2013_module.c
Here is a bit more on this.
When I configure w/ only a --prefix and CFLAGS=-save-temps, I can
examine libevent2013_module.i which contains the following:
# 7 "../../../../../opal/mca/event/libevent2013/libevent2013_module.c" 2
# 1
"../../../../opal/mca/hwloc/hwloc132/hwloc/include/private/auto
Thanks, Ralph.
I am a little deficient in the autotools department.
So, I will probably only be able to retest after a new trunk tarball is
generated tonight.
In the meantime I might be able to get more info on the config.h problem.
If I add -save-temps to CFLAGS I should be able to examine th
You are correct.
I'll fix.
Thanks!
On Feb 15, 2012, at 2:40 PM, Eugene Loh wrote:
> I had a question about our Fortran MPI_Improbe support.
>
> If I look at ompi/mpi/f77/improbe_f.c I see basically (lots of code removed):
>
>64void mpi_improbe_f(MPI_Fint *source, MPI_Fint *tag, MPI_F
I had a question about our Fortran MPI_Improbe support.
If I look at ompi/mpi/f77/improbe_f.c I see basically (lots of code
removed):
64void mpi_improbe_f(MPI_Fint *source, MPI_Fint *tag, MPI_Fint
*comm,
65 ompi_fortran_logical_t *flag, MPI_Fint
*message,
On Wed, Feb 15, 2012 at 8:08 PM, Jeff Squyres wrote:
> What is "gold"? Can you send all the information listed here (e.g., I don't
> know what version of Open MPI you're reporting about):
gold is the new binutils linker.
OS: Debian sid amd64 with g++-4.6, binutils-gold packages installed
OpenM
Something is definitely wrong -- 1.4us is way too high for a 0 or 1 byte HRT
ping pong. What is this all2all benchmark, btw? Is it measuring an
MPI_ALLTOALL, or a pingpong?
FWIW, on an older Nehalem machine running NetPIPE/MPI, I'm getting about .27us
latencies for short messages over sm and
I wanted to note that MacOS 10.4 on *X86* has the same "WEAK"
definitions in opal_config.h.
Yet it can build ompi-1.5.x with only WARNING about duplicate symbols.
I just tried, and the test code Matthias sent worked too:
$ ./bin/mpicc pmpi_test.c
/usr/bin/ld: warning multiple definitions of symb
I think the short answer is: Rolf is currently working on better GP-GPU
integration with Open MPI. :-)
On Feb 14, 2012, at 5:36 PM, Rolf vandeVaart wrote:
> There are several things going on here that make their library perform better.
>
> With respect to inter-node performance, both MVAPICH2
What is "gold"? Can you send all the information listed here (e.g., I don't
know what version of Open MPI you're reporting about):
http://www.open-mpi.org/community/help/
If VT is a problem, you can specify --disable-vt on OMPI's configure command
line (assuming this is OMPI 1.5.x).
On F
Thanks for testing, Paul.
I think we need an additional configure test which disables VT if
a) weak symbol support is disabled/not available
- or more precise -
b) configuring on PPC/Mac10.4 and the used GNU compiler version is older or
equal to 4.0.1
I prefer to option b) because VT (i.e. P
Hi,
I've found that otfcompress doesn't build with gold:
make[3]: Entering directory
`/home/storage_3/grib/ompi-build/ompi/contrib/vt/vt/extlib/otf/tools/otfcompress'
/bin/sh ../../libtool --tag=CC --mode=link clang -O3 -DNDEBUG
-finline-functions -fno-strict-aliasing -pthread
-I/home/storage
On Wed, Feb 15, 2012 at 10:56 AM, Paul Hargrove wrote:
> I strongly suspect that this is a Clang++ bug.
I don't know if it is a Clang bug, but here's my understanding of the problem.
TokenFactoryScopeC::create() boils down to this:
template
uint32_t
TokenFactoryScopeC::create( const void * loc
On Feb 14, 2012, at 6:47 AM, Denis Nagorny wrote:
> It seems that I was misled by copyright notices in source files which have no
> such exclusion. BTW Are you going to make copyright notices in source files
> more consistent with such one in README file?
We tried to make as few edits to the
Built on Linux --without-hwloc as well, with the fix.
On Wed, Feb 15, 2012 at 3:13 AM, Ralph Castain wrote:
> Hi Paul
>
> The rank_file component should not attempt to build if --without-hwloc is
> given - I've fixed that now. Thanks for reporting it.
>
> With that fix, I was able to build the t
Hi Paul
The rank_file component should not attempt to build if --without-hwloc is
given - I've fixed that now. Thanks for reporting it.
With that fix, I was able to build the trunk on Mac - testing Linux now. I
haven't checked for the config.h confusion you report, though - just noting
that it bu
Strangely enough, the 1.5 branch fails on Altix in a manner nearly opposite
that of the trunk:
Making all in tools/wrappers
> make[2]: Entering directory
> `/mnt/home/c_phargrov/OMPI/openmpi-1.5-latest-linux-ia64/BLD/opal/tools/wrappers'
> CC opal_wrapper.o
> CCLD opal_wrapper
> ../../..
See responses mixed in below.
On Wed, Feb 15, 2012 at 1:02 AM, Matthias Jurenz <
matthias.jur...@tu-dresden.de> wrote:
> Unfortunately, we don't have access to a PPC system with MacOS 10.4 to try
> to
> reproduce the error.
>
Not too surprising. I'll see what I can do to help resolve the probl
Unfortunately, we don't have access to a PPC system with MacOS 10.4 to try to
reproduce the error.
Paul, could you please check for the definition of the macro
OPAL_HAVE_WEAK_SYMBOLS in ompi_config.h? I assume that the ancient GNU compiler
on PPC/MacOS10.4 does not support weak-symbols which ca
When trying to build the OMPI trunk or the 1.5 branch with clang-3.0, I
cannot build VT.
If have tried both MacOS 10.7 and FreeBSD-9.0-RELEASE.
In all four builds (2 branches X 2 OSes) the failure appears to be "deep"
in the C++ STL.
I strongly suspect that this is a Clang++ bug.
However, I am rep
I've configured the ompi trunk (nightly tarball 1.7a1r25927) on an SGI
Altix.
I used no special arguments indicating that this is an Altix, and there
does not appear to be an altix-specific file in contrib/platform.
My build fails as follows:
make: Entering directory
> `/mnt/home/c_phargrov/OMPI/
On 2/14/2012 10:13 PM, Paul H. Hargrove wrote:
On the linux/mips64el platform I also tried the PathScale 3.3a
compilers on both branches.
On both branches the atomic_*_noinline tests all PASS, which validates
these patches.
On trunk all the tests in test/asm are PASSing.
However, the versions
The attached patches fix three problems with the non-inline ASM for MIPS
(and MIPS64EL):
1) ".set rerorder" was placed too early.
This was causing loss of the SLTU instruction in the jump delay
slot which follows the return instruction. Since that SLTU is
used to set the return value, t
29 matches
Mail list logo
