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
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
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
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:
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
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
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 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
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.
>
>
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-
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
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
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
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.
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
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
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
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, 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
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
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
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
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
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
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
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
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
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
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
29 matches
Mail list logo
