General informations:
3 node Opteron cluster, 24CPUs, Melanox Infiniband 10Gb interconnect
Debian Lenny 5.0
self build kernel from kernel.org: 2.6.32.12, all NFS functions
available from kernel side
self build NFS-utils 1.2.2 from debian source of sid: nfs-ker
I have access to PGI compilers 10.{3,4,5,8} on an Opteron/InifiniBand
cluster running Scientific Linux 5.4 (an RHEL derivative like the Centos
distro). I can try to reproduce Larry Baker's problems today with the
most recent 10.8 compiler. If there are other things I could/should be
trying to
Per the discussion on today's telecon, I've started working with Jeff on
refactoring the opal/util/if.c code into something more understandable without
changing the discovery logic. We are creating a framework that solely performs
interface discovery, leaving all of the interface wrapper functio
More specifically: if.h has not been changed (except for its finalize function).
So all this change does it un-spaghettify the if.c code. From an interface
perspective, the rest of the code base isn't even aware that this change
occurred.
Also, I think Ralph meant the following URL:
https
I went to try to reproduce the problem Larry Baker reported w/ the PGI
10.3 compilers and undefined references in libopen-pal.so when linking
opal_wrapper. Instead I encountered a different error that does not (as
best I can tell) correspond to any of the issues Larry has reported
recently. O
Okay, release candidate 1 for 1.4.3 is now available on the web site. Please
give it a whirl.
http://www.open-mpi.org/software/ompi/v1.4/
Ralph
With PGI-10.5 I see the same 4 warnings in atomic.h that Jeff reported
in June with PGI-7.0.7
http://www.open-mpi.org/community/lists/devel/2010/06/8060.php
Other than that, I can report a clean build w/ PGI-10.5.
I will try 10.8 next, but will only report to the list only if there are
prob
Trying to build 1.5rc5 with icc-11.1.046 is failing in otfprofile.cpp -
the same file I saw problems with when using the PGI compilers.
$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
$ uname -a
Linux jaguar-ext3 2.6.16.60-0.42.7-smp #1 SMP Tue Nov
Building w/ icc-11.1.046 on x86-64 works with some warnings.
In addition to the numerous "188" warnings and the single instance of
"279" that I reported seeing for 1.5rc5
(http://www.open-mpi.org/community/lists/devel/2010/08/8320.php), there
is one additional warning:
libtool: compile: icc -
Testing on Sun C 5.10 on OpenSolaris yield many warnings (below), but
does build to completion.
I have run a successful "make check", making me doubt that any of the
atomic.h warnings indicate real problems.
$ uname -a
SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc
$ cc -V
cc: Sun C 5.10 SunOS_
In addition to the atomic.h and Anachronism warnings seen w/ 1.4.3rc1
(http://www.open-mpi.org/community/lists/devel/2010/08/8322.php), I find
some "new" warnings in 1.5rc5.
$ uname -a
SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc
$ cc -V
cc: Sun C 5.10 SunOS_i386 2009/06/03
usage: cc [ option
Thanks Paul -- reported in #2544.
On Aug 24, 2010, at 6:07 PM, Paul H. Hargrove wrote:
> I went to try to reproduce the problem Larry Baker reported w/ the PGI 10.3
> compilers and undefined references in libopen-pal.so when linking
> opal_wrapper. Instead I encountered a different error that
Also reported in #2544. Thanks!
On Aug 24, 2010, at 7:14 PM, Paul H. Hargrove wrote:
> Trying to build 1.5rc5 with icc-11.1.046 is failing in otfprofile.cpp - the
> same file I saw problems with when using the PGI compilers.
>
> $ cat /etc/SuSE-release
> SUSE Linux Enterprise Server 10 (x86_64
A build of 1.5rc5 with gcc on OpenSolaris/x86 agrees with my Sun C build
(http://www.open-mpi.org/community/lists/devel/2010/08/8323.php) about
type sloppiness in common_sm_mmap.c.
$ uname -a
SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc
$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802
This indicates that two contiguous C long double types are not identical to a
Fortran COMPLEX32 type.
Paul, if you still have the config.log and opal_config.h I would like to take a
look at them.
Thanks,
george.
On Aug 24, 2010, at 19:38 , Paul H. Hargrove wrote:
> Building w/ icc-11.1.046
On Aug 24, 2010, at 20:40 , Paul H. Hargrove wrote:
> "../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170:
> warning: impossible constraint for "%1" asm operand
__asm__ __volatile__(
SMPLOCK "addl %1,%0"
:"=m" (*v)
An attempt to compile 1.5rc5 on Linux/IA64 w/ icc-10.0.008 failed:
$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (ia64)
VERSION = 10
PATCHLEVEL = 1
$ cat /etc/sgi-release
SGI ProPack 5SP4 for Linux, Build 504r4-0801072302
$ uname -a
Linux tg-login3.pople.psc.teragrid.org
2.6.16.60-0.
> ../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:201:
> warning: assignment from incompatible pointer type
> ../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:207:
> warning: assignment from incompatible pointer type
This belongs to an assignment to the iov_ba
My attempt to build 1.4.3rc1 w/ icc-10.1.008 is failing.
Everything (except the tmpfile name in the error message, of course) is
identical to what I recently reported for 1.5rc5:
http://www.open-mpi.org/community/lists/devel/2010/08/8329.php
-Paul
Ralph Castain wrote:
Okay, release candida
Paul,
Thanks for the files. It appears that our configure script detected that a
Fortran REAL*16 bit representation differs from a C long double. This is a
pretty weird scenario, where a Fortran type cannot be represented in C. As we
only support C MPI_Op there is no "simple" way we can support
I suspect that the FORTRAN REAL*16 is a 16-byte floating point type
while C's "long double" may just be the x86 10-byte type. I'd not be
surprised if icc has some option to get 16-byte long double. I don't
have time to hunt for such an option, but if somebody know the required
compiler option
I see the following in the Compiler Notes of the Open MPI README (both
1.5rc5 and 1.4.3rc1)
- Open MPI does not support the Sparc v8 CPU target, which is the
default on Sun Solaris. The v8plus (32 bit) or v9 (64 bit)
targets must be used to build Open MPI on Solaris. This can be
done by i
By this point you all must either love or hate me, but I still have more
platforms to test...
This time it is FreeBSD-8.0 on an i386, and I can report that both RCs
are successful.
However, the build of 1.4.3rc1 produces MANY instances of the following:
In file included from [SOMEFILE:SOMELI
Following George's advice, I made the following change (NOT yet
conditional on Sun compiler), and can confirm that it eliminates the
warnings in atomic.h and "make check" still passes.
-Paul
--- openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h.orig Tue Aug
24 18:40:55 2010
+++ openmpi-1
The following was seen in a "make check" with 1.5rc5 on FreeBSD-8.0/i386
w/ gcc-4.2.1, but I don't think that these warnings are platform
specific. These warnings do not occur with 1.4.3rc1
I was vaguely recalling that gcc-4.2.1 might be one of the versions that
generates incorrect "discards
I have not sifted through logs for warnings, but can report that 1.5rc5
builds and passes "gmake check" w/ gcc-3.3.5 on OpenBSD 4.6 on an i386.
HOWEVER, 1.4.3rc1 fails to build due to errors in ROMIO:
$ uname -a
OpenBSD obsd46-i386.my.domain 4.6 GENERIC#58 i386
$ gcc --version
gcc (GCC) 3.3.5
Building both of the new RCs on OpenBSD 4.6 for i386 is warning that
malloc.h is obsolete. The files/lines producing the warnings are nearly
the same, but I provide both lists below for completeness.
$ uname -a
OpenBSD obsd46-i386.my.domain 4.6 GENERIC#58 i386
$ gcc --version
gcc (GCC) 3.3.5
Both 1.5rc5 and 1.4.3rc1 build and pass "gmake check" on my NetBSD/i386
platform.
However, for 1.4.3rc1 (but NOT for 1.5rc5) I see numerous instances of
In file included from [SOMEFILE:SOMELINE]:
../../opal/include/opal/sys/cache.h:33:1: warning: "CACHE_LINE_SIZE"
redefined
In file included fr
28 matches
Mail list logo
