I have supposed that BML add_procs() is called by PML and I see such
call in ompi_mpi_init() as ".. ret = MCA_PML_CALL(add_procs(procs,
nprocs));...". Moreover BML add_procs() is called by SPML (OSHMEM`s PML)
in oshmem_shmem_init().
So it looks that all should be correct. Or am I still missing
I missed the call in the SPML. If that's already there (it would have
caused major problems previously, which is why I assumed it wasn't), then
you're good.
Brian
On 1/16/14 10:12 PM, "Igor Ivanov" wrote:
>I have supposed that BML add_procs() is called by PML and I see such
>call in ompi_mpi_i
Current status of my seven issues as of tonight's trunk tarball
(1.9a1r30302)
1. opal/util/path.c
CLOSED
2. oshem_info reports oshmem:bindings:fort:yes unconditionally
CLOSED (except for harmless orphaned call to OSHMEM_SETUP_CFLAGS)
3. configure refuses btl:verbs on Solaris
CLOSED
4. oob:tcp n
My builds of the trunk with pgcc-13.10 turned up the following warnings:
PGC-W-0095-Type cast required for this conversion
(/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/opal/mca/db/hash/db_hash.c:
354)
PGC-W-0095-Type cast required for this conversion
Building trunk (1.9a1r30302) and 1.7 (1.7.4rc2r30303) with --enable-debug
on a linux/x86 (32-bit) platform revealed many "cast to pointer from
integer of different size" warnings that could/should be avoided with an
intermediate cast to intptr_t or uintptr_t.
On trunk the only ones are in the ope
Fixed. Slated for v1.7.5, because it's not too important.
On Jan 13, 2014, at 11:20 PM, Paul Hargrove wrote:
> I have a Linux system on which there is a fuse mount.
> Users other than the owner get EPERM from statfs().
>
> When opal_path_nfs() sees the EPERM it drops one path component and do
Paul --
Looks like this wasn't actually fixed until r30305.
On Jan 16, 2014, at 11:31 PM, Paul Hargrove wrote:
>
> The following commit claimed to have resolved the OSHMEM_SETUP_CFLAGS issues:
>
> r30286 | miked | 2014-01-14 05:23:44 -0800 (Tue, 14 Jan 2014) | 5 lines
>
> OSHMEM: fix fortra
On Jan 17, 2014, at 1:30 AM, Paul Hargrove wrote:
> [snipping CLOSED issues]
>
> 4. oob:tcp not using loopback interface for single-node runs
> NOT YET, but not critical
Ralph: is this deferred to v1.7.5?
> 5. pgi-8 and pgi-9 fail building mpi_f08
> Looks like Jeff fixed the only real issue ea
Hi Paul
Looking at these, I'm a tad puzzled. It would appear that PGI is complaining
about the fixed string being passed in the last three cases as there is no
(const char*)foo being used in those areas. Yet we use that same logic
elsewhere and your report isn't showing those as warnings.
Do y
After discussion on the telecon, we decided to:
1. let the modex be non-blocking so we can fall thru - only when the
corresponding MCA param is set!
2. do not modify the modex_recv to add the callback as the MPI layer really
doesn't know how to handle this in an async fashion. Modifying that be
Paul, Ralph,I had several issues in 2010 with with PGI pgcc being overly picky about type mismatches. Attached are my e-mails from that time. I was working on NetCDF and OpenMPI. In the OpenMPI report (17 Aug 2010), I found problems in conditional expressions. The last e-mail in the thread from
Ralph,
You are probably right that the string literals are a likely cause (type
char[] ? ).
I will poke at this a bit by adding (char *) casts to see which argument(s)
are actually the cause and get back to you.
-Paul
On Fri, Jan 17, 2014 at 8:56 AM, Ralph Castain wrote:
> Hi Paul
>
> Looking
Paul,
From what I can see in the arguments to OPAL_OUTPUT_VERBOSE() in line 356 at
https://bitbucket.org/ompiteam/ompi-svn-mirror/src/f48eeda443104a64dc89e4f5fab4c940e44d8615/opal/mca/db/hash/db_hash.c,
this is the same PGI bug I reported 22 Jul 2010, which was assigned TPR 17139.
> Customer i
Larry,
So, if I follow your report correctly is is probably the "static" (not the
"const") property of the string literals' type that leads pgcc to warn. If
that is the case, then I agree that this is NOT a warning that is
consistent with the C standard's rules for type compatibility. Thus I
agr
Hmmm...I hate chasing compiler bugs, and since this is only a warning, I would
tend to defer making changes and just let folks push on PGI to fix their bug.
Anyone object to that strategy?
On Jan 17, 2014, at 12:04 PM, Paul Hargrove wrote:
> Larry,
>
> So, if I follow your report correctly i
Paul,
> So, if I follow your report correctly is is probably the "static" (not the
> "const") property of the string literals' type that leads pgcc to warn. If
> that is the case, then I agree that this is NOT a warning that is consistent
> with the C standard's rules for type compatibility.
Ralph,
I might be the most active lurker on Earth, but I am still that: an
individual outside the OMPI core developers who follows the devel list.
So, excepting bugs that cause me actual harm (and this is NOT one) I am
usually happy to defer to the core developers.
As I just sent in response to
On Jan 17, 2014, at 12:44 PM, Paul Hargrove wrote:
> Ralph,
>
> I might be the most active lurker on Earth, but I am still that: an
> individual outside the OMPI core developers who follows the devel list. So,
> excepting bugs that cause me actual harm (and this is NOT one) I am usually
> h
Building the v1.7 tarball (1.7.4rc2r30303) with AMD's Open64 compilers
(v4.5.2) I hit the errors shown in the attached make.log (too long to
cut-and-paste).
I've also attached config.log and configure's stdout.
"We don't care about that compiler" is an acceptable (to me) answer, but I
am reporting
Building the v1.7 tarball (1.7.4rc2r30303) with the PathScale compilers
(v4.0.12.1) I hit the errors shown below. I've attached config.log and
configure's stdout.
"We don't care about that compiler" is an acceptable (to me) answer, but I
am reporting this for completeness.
-Paul
PPFC mpi-
FWIW: PathScale 3.2.99 compilers yield the same complaints.
-Paul
On Fri, Jan 17, 2014 at 4:59 PM, Paul Hargrove wrote:
> Building the v1.7 tarball (1.7.4rc2r30303) with the PathScale compilers
> (v4.0.12.1) I hit the errors shown below. I've attached config.log and
> configure's stdout.
>
>
I am trying to build the 1.7 nightly tarball (1.7.4rc2r30303) on a
Linux/PPC system with the xlc-11.1 compilers configured for 32-bit output:
$ export OBJECT_MODE=32
$ [pathto]/configure CC=xlc CXX=xlC FC=xlf90 --enable-debug --prefix=...
The build fails with:
Making all in mpi/cxx
make[2]: Ente
Back in Sep 2012 I reported that the trunk was broken with IBM's Fortran
compilers. The last email I could find on that thread is
http://www.open-mpi.org/community/lists/devel/2012/09/11519.php
Well, the errors with current 1.7 nightly tarball (1.7.4rc2r30303) may have
changed slightly, but thing
I just noticed that I get unknown compiler family in all my builds:
checking for compiler familyid... 0
checking for compiler familyname... UNKNOWN
The following in config.log shows why:
configure:27774: checking for compiler familyid
configure:27804: xlc -o conftest -q64 -g
-I/home/hargrove/SCR
Trying to build 1.7.4rc2r30303 with gcc on linux/mips32 yields the
following failure:
CXX mpicxx.lo
/home/phargrov/OMPI/openmpi-1.7.4-latest-linux-mips32/openmpi-1.7.4rc2r30303/ompi/mpi/cxx/mpicxx.cc:31:2:
warning: #ident is a deprecated GCC extension
In file included from
/home/phargrov/OM
ouch - will fix. Thanks Paul!
On Jan 17, 2014, at 6:38 PM, Paul Hargrove wrote:
> I just noticed that I get unknown compiler family in all my builds:
>
> checking for compiler familyid... 0
> checking for compiler familyname... UNKNOWN
>
> The following in config.log shows why:
>
> configure:
Yup, gcc on ppc32 (one nightly later, btw) fails just as mips32 did:
make[2]: Entering directory
`/home/phargrov/OMPI/openmpi-1.7.4-latest-linux-ppc32/BLD/ompi/mpi/cxx'
CXX mpicxx.lo
In file included from
/home/phargrov/OMPI/openmpi-1.7.4-latest-linux-ppc32/openmpi-1.7.4rc2r30318/opal/class
Yup, looks fine in the nightly (1.9a1r30319) tarball.
-Paul
On Fri, Jan 17, 2014 at 7:14 AM, Jeff Squyres (jsquyres) wrote:
> Paul --
>
> Looks like this wasn't actually fixed until r30305.
>
>
> On Jan 16, 2014, at 11:31 PM, Paul Hargrove wrote:
>
> >
> > The following commit claimed to have
Well, the good news is that the trunk builds fine on ppc32.
So, I suspect there is a fix that needs a CMR.
I'll poke around a bit, to see if I can locate the necessary changes.
My mips32 system is slow, but I am hoping for similar results on trunk.
-Paul
On Fri, Jan 17, 2014 at 7:49 PM, Paul Ha
29 matches
Mail list logo
