Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm wrote: > Is there a reason why the > current implementations of opal atomics (add, cmpset) do not return the > old value? > Because some CPUs don't implement such an atomic instruction? On any CPU one *can* certainly synthesize the

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

I have license for PGI and installations of 14.1 and 14.4 I will see what I can do today in terms of testing. -Paul On Tue, Jul 29, 2014 at 4:23 PM, Jeff Squyres (jsquyres) wrote: > Tetsuya -- > > I am unable to test with the PGI compiler -- I don't have a license. I >

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

gt; Larry Baker > US Geological Survey > 650-329-5608 > ba...@usgs.gov > > > > On 29 Jul 2014, at 4:25 PM, Paul Hargrove wrote: > > I have license for PGI and installations of 14.1 and 14.4 > I will see what I can do today in terms of testing. > > -Paul > >

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Tue, Jul 29, 2014 at 4:23 PM, Jeff Squyres (jsquyres) wrote: > Tetsuya -- > > I am unable to test with the PGI compiler -- I don't have a license. I > was hoping that LANL would be able to test today, but I don't think they > got to it. > > Can you send more details? > >

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Tue, Jul 29, 2014 at 6:33 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > I am trying again with an explicit --enable-mpi-fortran=usempi at > configure time to see what happens. > Of course that should have said --enable-mpi-fortran=usempif08 -- P

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Tue, Jul 29, 2014 at 6:38 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > On Tue, Jul 29, 2014 at 6:33 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> I am trying again with an explicit --enable-mpi-fortran=usempi at >> configure time to see what happens.

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

_proc > INTERFACE > SUBROUTINE binky(user_fn) > USE proc_mod > PROCEDURE(MPI_User_function) :: user_fn > END SUBROUTINE > END INTERFACE > END PROGRAM > > i do not have a PGI license, could you please confirm the PGI compiler > fails compiling the test above ? > > Che

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

OMPI_BUILD_FORTRAN_USEMPIF08_BINDINGS=0])]) > > > from the sources and #4590, f08 binding is intentionally disabled since > PGI compilers does not support PROCEDURE. > i agree this is really bad for PGI users :-( > > Jeff, can you comment on that ? > > Cheers, >

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

wrote: > On Jul 30, 2014, at 12:36 AM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > Unfortunately, this (and > https://svn.open-mpi.org/trac/ompi/changeset/31588 that followed) > represent a REGRESSION in that between 1.8.1 and 1.8.2rc2 Open MPI has lost > support fo

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Tetsuya, I found that the behavior of pgf90 changed somewhere between versions 13.6 and 14.1. My previous reports were mostly based on my testing of 13.6. So, I have probably been seeing an issue entirely different than yours. I am testing 14.4 now and hope to be able to reproduce the problem

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Jeff, I can now reproduce Tetsuya's original problem, using a build of 1.8.2rc2 with PGI 14.4. $ INST/bin/mpifort ../test.f /scratch/scratchdirs/hargrove/pgf90pdegT3bhBmEq.o: In function `.C1_283': test.f:(.data+0x6c): undefined reference to `mpi_f08_interfaces_callbacks_' test.f:(.data+0x74):

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Wed, Jul 30, 2014 at 6:15 PM, wrote: [...] > Strange thing is that openmpi-1.8 with PGI14.7 works fine. > What's the difference with openmpi-1.8 and openmpi-1.8.2rc2? > [...] Tetsuya, Now that I can reproduce the problem you have reported, I am building 1.8.1

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Wed, Jul 30, 2014 at 6:20 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > On Wed, Jul 30, 2014 at 6:15 PM, <tmish...@jcity.maeda.co.jp> wrote: > [...] > >> Strange thing is that openmpi-1.8 with PGI14.7 works fine. >> What's the difference w

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Wed, Jul 30, 2014 at 8:53 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: [...] > I have a clear answer to *what* is different (below) and am next looking > into the why/how now. > It seems that 1.8.1 has included all dependencies into libmpi_usempif08 > w

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Gilles, Just as you speculate, PGI is creating a _-suffixed reference to the module name: $ pgf90 -c test.f90 $ nm -u test.o | grep f08 U mpi_f08_sizeof_ U mpi_f08_sizeof_mpi_sizeof_real_s_4_ You suggested the following work-around in a previous email: $

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca wrote: > Paul, I know you have a pretty diverse range computers. Can you try to > compile and run a "make check" with the following patch? I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever subset of those is

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca <bosi...@icl.utk.edu> > wrote: > >> Paul, I know you have a pretty diverse range computers. Can you try to >> compile and run a &

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

inal problem, so I fixed that, too (which was a direct > consequence of the first fix). > > Should be fixed in the trunk now; we tested with pgfortran on Craig > Rasmussen's cluster (many thanks, Craig!). > > CMR is https://svn.open-mpi.org/trac/ompi/ticket/4519. > > > > >

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Nevermind my suggestion to revise examples/hello_usempif08.f90 I've just determined that it is already sufficient to reproduce the problem. (So now I need to see what's wrong in my testing scripts). -Paul On Thu, Jul 31, 2014 at 7:04 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: &g

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

> needed for these less common architectures. > > George. > > > > On Thu, Jul 31, 2014 at 7:24 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> >> >> On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove <phhargr...@lbl.gov> >> wrote: >> &

[OMPI devel] trunk link failure on Solaris-10/SPARC

$ INST/bin/mpirun -mca btl sm,self -np 2 examples/ring_c' ld.so.1: ring_c: fatal: relocation error: file /home/hargrove/OMPI/openmpi-trunk-solaris10-sparcT2-ss12u3-v8plus/INST/lib/openmpi/mca_pml_ob1.so: symbol alloca: referenced symbol not found This platform has worked in the past. I will be

Re: [OMPI devel] [OMPI svn] svn:open-mpi r32388 - trunk/ompi/mca/pml/ob1

In general I am only setup to build from tarballs, not svn. However, I can (and will) apply this change manually w/o difficulty. I will report back when I've had a chance to try that. I already have many builds in-flight to test George's atomics patch and am in danger of confusing myself if I am

Re: [OMPI devel] [OMPI svn] svn:open-mpi r32388 - trunk/ompi/mca/pml/ob1

> list. > > #include did not help : > http://www.open-mpi.org/community/lists/users/2014/07/24883.php > > I will try if i can reproduce and fix this issue on a solaris10 (but x86) > VM > > BTW, are you using the GNU compiler ? > > Cheers, > > Gilles > > On

Re: [OMPI devel] [OMPI svn] svn:open-mpi r32388 - trunk/ompi/mca/pml/ob1

gt; George just made a good point, you should test with his patch first > > if it still does not work, could you try to mix gnu and sun compilers ? > configure ... CC=/usr/sfw/bin/gcc CXX=/usr/sfw/bin/g++ FC= fortran compiler> > > Cheers, > > Gilles > > On 2014

[OMPI devel] [1.8.2rc3] Build failure on FreeBSD (missing header)

/home/phargrov/OMPI/openmpi-1.8.2rc3-freebsd10-amd64/openmpi-1.8.2rc3/orte/mca/ess/base/ess_base_std_app.c:412:36: error: use of undeclared identifier 'S_IRUSR' fd = open(myfile, O_CREAT, S_IRUSR); ^ To fix this it was sufficient to add the following 3

Re: [OMPI devel] Trunk broken for PPC64?

, > > Gilles > > On 2014/08/01 12:30, Ralph Castain wrote: > > Yes, I fear this will require some effort to chase all the breakage down > given that (to my knowledge, at least) we lack PPC machines in the devel > group. > > > On Jul 31, 2014, at 5:46 PM

Re: [OMPI devel] Trunk broken for PPC64?

] *** End of error message *** /lib/libc.so.6.1(_IO_vfprintf-0x998610)[0x204b15d0] [altix:20418] [ 3] /lib/libc.so.6.1(+0x82860)[0x204b2860] [altix:20418] [ 4] /lib/libc.so.6.1(_IO_vfprintf-0x99f140)[0x2040] On Thu, Jul 31, 2014 at 11:47 PM, Paul Hargrove <phha

Re: [OMPI devel] 1.8.2rc3 now out

Note that the Solaris unresolved alloca problem George fixed in r32388 is still present in 1.8.2rc3. I have manually confirmed that the same patch resolves the problem in 1.8.2rc3. -Paul On Thu, Jul 31, 2014 at 9:44 PM, Ralph Castain wrote: > Usual place - this is a

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

Why do you want to add new versions? This will lead to having two, > almost > >>> identical, sets of atomics that are conceptually equivalent but > different > >>> in terms of code. And we will have to maintained both! > >>> I did a similar change in a fo

Re: [OMPI devel] 1.8.2rc3 now out

or*11:45:01* *** > MPI_ERRORS_ARE_FATAL (processes in this communicator will now > abort,*11:45:01* ***and potentially your MPI job)*11:45:01* > [hpctest:2763] Local abort before MPI_INIT completed successfully; not able > to aggregate error messages, and not able to guarantee that all

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

ill have to maintained both! > >>> I did a similar change in a fork of OPAL in another project but > instead of > >>> adding another flavor of atomics, I completely replaced the available > ones > >>> with a set returning the old value. I can bring the code over

[OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)

I am seeing the following on OpenBSD/amd64 with "make V=1": Making all in tools/wrappers /bin/sh ../../../libtool --tag=CC--mode=link gcc -std=gnu99 -g -finline-functions -fno-strict-aliasing -pthread -export-dynamic -o opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lutil -lm

Re: [OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)

n a later version than we include) > > > On Aug 1, 2014, at 4:07 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > I am seeing the following on OpenBSD/amd64 with "make V=1": > > Making all in tools/wrappers > /bin/sh ../../../libtool --tag=CC--mode=l

[OMPI devel] Trak missing Versions for 1.8.x

I was just in Trak to open a new ticket and noticed that the Version pull-down lacks entries for 1.8 and 1.8.1. -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley

Re: [OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)

be happy to > proceed. > > Thanks > Ralph > > > On Aug 2, 2014, at 12:49 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Ralph, > > My position on support for OpenBSD is the same as the numerous other > operating systems, cpu architectures and compilers I help

Re: [OMPI devel] Trak missing Versions for 1.8.x

es to old > releases. > > On Aug 2, 2014, at 12:59 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > I was just in Trak to open a new ticket and noticed that the Version > pull-down lacks entries for 1.8 and 1.8.1. > > -Paul > > -- > Paul H. Hargrove

Re: [OMPI devel] Trak missing Versions for 1.8.x

hy we would support > creation of tickets for releases that we know we'll never fix > > > On Aug 2, 2014, at 2:26 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Not sure I understood that reply. > > I see Version going back to 1.0, but none for the *current* relea

[OMPI devel] trunk warnings on x86

Looks like on a 32-bit platform a (uintptr_t) cast is desired in the OMPI_CAST_RTE_NAME() macro. Warnings from current trunk tarball attributable to the missing case include: /home/pcp1/phargrov/OMPI/openmpi-trunk-linux-x86-gcc/openmpi-1.9a1r32406/ompi/runtime/ompi_mpi_abort.c:89: warning: cast

Re: [OMPI devel] trunk warnings on x86

teresting point. This is a pointer to a 64-bit > number. Will uintptr_t resolve that problem on such platforms? > > On Aug 2, 2014, at 8:12 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Looks like on a 32-bit platform a (uintptr_t) cast is desired in the > OMPI_CAST_RT

[OMPI devel] [1.8.2rc3] another openib bug (#4377)

I have a pair of x86/linux (32 bit) hosts connected by Mellanox Tavor HCAs. I have no idea if (or why) this has only appeared on this system, but I find that blt:openib thinks the INI file says to ignore these HCAs. See the 4th line below:

Re: [OMPI devel] [1.8.2rc3] another openib bug (#4377)

On Sun, Aug 3, 2014 at 12:49 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > BTW: > Even with the "ignore_device=1" problem fixed, I can't get btl:openib > running on x86. > So, there may be additional reports in the next few hours. > That turned out to be the

[OMPI devel] [1.8.2rc3] static linking fails on linux (openpty undefined)

I've configured the 1.8.2rc3 tarball with "--enable-static --disable-shared" on a fairly standard Linux/x86-64 platform. While there are no problems on the same platform w/o these configure flags, with them I cannot link any application codes. $ mpicc -ghello_c.c -o hello_c

Re: [OMPI devel] [1.8.2rc3] static linking fails on linux (openpty undefined)

-1.8.2rc3-linux-x86_64-pgi-14.1/INST/lib -lmpi -lopen-rte -lopen-pal -lm -lpciaccess -ldl -ltorque -lrt -lnsl -lutil Searching for relevant differences now... -Paul On Sun, Aug 3, 2014 at 4:58 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > I've configured the 1.8.2rc3 tarball wi

Re: [OMPI devel] [1.8.2rc3] static linking fails on linux when not building ROMIO

ding ROMIO -Paul On Sun, Aug 3, 2014 at 6:22 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > Hmm, > > On a different Linux/x86-64 host things work as expected with '-lutil' > linked explicitly: > > $ ./INST/bin/mpicc -showme BLD/examples/hello_c.c > pgcc BLD/exampl

[OMPI devel] 1.8.2rc3 cosmetic issues in configure

It looks like four instances of AC_MSG_CHECKING are missing an AC_MSG_RESULT or have other configure macros improperly nested between the two: checking for epoll support... checking for epoll_ctl... yes yes checking for working epoll library interface... yes yes checking if user requested CMA

[OMPI devel] oshmem enabled by default

In both trunk and 1.8.2rc3 the behavior is to enable oshmem by default. In the 1.8.2rc3 tarball the configure help output matches the behavior. HOWEVER, in the trunk the configure help output still says oshmem is DISabled by default. {~/OMPI/ompi-trunk}$ svn info | grep "Revision" Revision:

Re: [OMPI devel] [1.8.2rc3] static linking fails on linux when not building ROMIO

t to Jeff. I took > a crack at fixing it, but came up short :-( > > > On Aug 3, 2014, at 10:46 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > I've identified the difference between the platform that does link libutil > and the one that does not. > > 1) libu

[OMPI devel] [vt] --with-openmpi-inside configure argument

I noticed that Open MPI is passing --with-openmpi-inside=1.7 in the arguments passed to ompi/contrib/vt/vt/configure and ompi/contrib/vt/vt/extlib/otf/configure The extlib/otf case just tests if the value is set, but the top-level vt/configure is checking for the specific string

[OMPI devel] minor atomics nit

Running "make dist" on trunk I see: --> Generating assembly for "SPARC" "default-.text-.globl-:--.L-#-1-0-1-0-0" Could not open ../../../opal/asm/base/SPARC.asm: No such file or directory Which is apparent because the following lines were never removed from opal/asm/asm-data.txt # default

Re: [OMPI devel] oshmem enabled by default

en (enable or > disable), then don't attempt to build OSHMEM unless we are on a Linux > platform. Default to building if we are on Linux for now, pending the > outcome of the Debian situation. > > > On 2014/08/05 6:41, Paul Hargrove wrote: > > In both trunk and 1.8.2r

Re: [OMPI devel] [vt] --with-openmpi-inside configure argument

Bert, It is just an observation of something that could easily break in the future. The code is correct as written. So, no immediate action is required. -Paul On Tue, Aug 5, 2014 at 12:04 AM, Bert Wesarg <bert.wes...@tu-dresden.de> wrote: > On 08/05/2014 02:40 AM, Paul Hargrove wrot

Re: [OMPI devel] [1.8.2rc3] static linking fails on linux when not building ROMIO

7:56, Ralph Castain wrote: > > My thought was to post initially as a blocker, pending a discussion with > Jeff at tomorrow's telecon. If he thinks this is something we can fix in some > central point (thus catching it everywhere), then it could be quick and worth > doing. Howeve

Re: [OMPI devel] v1.8.2 still held up...

Ralph, I will hopefully be able to test Gilles's patch for 4834 on applicable systems today or tomorrow. So, I can soon answer whether the patch fixes all the problems I reported. However, I cannot speak at all to the desirability of the approach relative to the build infrastructure. I think

Re: [OMPI devel] v1.8.2 still held up...

On Thu, Aug 7, 2014 at 8:03 PM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > > * Siegmar reports another alignment issue on Sparc > > http://www.open-mpi.org/community/lists/users/2014/07/24869.php > > > Is there any chance r32449 fixes the issue ? > > i found the problem

Re: [OMPI devel] v1.8.2 still held up...

On Thu, Aug 7, 2014 at 8:03 PM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > > * static linking failure - Gilles has posted a proposed fix, but > somebody needs to approve and CMR it. Please see: > > https://svn.open-mpi.org/trac/ompi/ticket/4834 > > Jeff made a better

[OMPI devel] circular library dependence prevents static link on Solaris-10/SPARC

Testing r32448 on trunk for trac issue #4834, I encounter the following which appears unrelated to #4834: CCLD orte-info Undefined first referenced symbol in file ompi_proc_local_proc

Re: [OMPI devel] circular library dependence prevents static link on Solaris-10/SPARC

oup/group.h" > > > > > > > > > On Aug 8, 2014, at 5:33 AM, Jeff Squyres (jsquyres) < > jsquy...@cisco.com> wrote: > > > > > >> Weirdness; I don't see any name like that in the SM BTL. > > >> > > >> I see it us

Re: [OMPI devel] v1.8.2 still held up...

On Thu, Aug 7, 2014 at 10:55 AM, Ralph Castain wrote: > * static linking failure - Gilles has posted a proposed fix, but somebody > needs to approve and CMR it. Please see: > https://svn.open-mpi.org/trac/ompi/ticket/4834 > Jeff moved the fix to v1.8 in r32471. I

Re: [OMPI devel] v1.8.2 still held up...

On Thu, Aug 7, 2014 at 10:55 AM, Ralph Castain wrote: > * fixes to coll/ml that expanded to fixing page alignment in general - > someone needs to review/approve it: > https://svn.open-mpi.org/trac/ompi/ticket/4826 > I've been able to confirm that the nightly tarball

[OMPI devel] [v1.8] java bindings build failure

Below are errors from trying tonight's v1.8 tarball on one of the few systems I have access to with java. The trunk has the same errors but with all the line numbers increased by exactly 18. -Paul Making all in java make[3]: Entering directory

[OMPI devel] [v1.8] illegal commas after last item in enum

The Solaris Studio 12.3 C++ compiler warns about commas after the last item in an enum. While these commas are legal in C99, they are ILLEGAL in C++ prior to C++11 The warnings below list the four instances I encountered while building the C++ bindings, but there might be others. -Paul

Re: [OMPI devel] [v1.8] java bindings build failure

Ralph, /usr/java/jdk1.6.0_21 -Paul On Fri, Aug 8, 2014 at 9:51 PM, Ralph Castain <r...@open-mpi.org> wrote: > This seems odd - I'm not seeing any warnings or errors when building Java. > Which JDK version do you have? > > On Aug 8, 2014, at 9:31 PM, Paul Hargrove <phha

[OMPI devel] [v1.8] 32-bit c++ build failure with Sun compilers

A problem Siegmar reported on trunk over a year and a half ago is breaking a 32-bit build of the v1.8 branch with the Sun C++ compiler: Siegmar's report appears in http://www.open-mpi.org/community/lists/users/2013/01/21269.php There are several warnings, but the error is (from my current build):

Re: [OMPI devel] v1.8.2 still held up...

And for the record: the IA64 platform passed too. On Sat, Aug 9, 2014 at 3:22 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > Thanks for all the testing! > > On Aug 8, 2014, at 11:21 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > > > > >

Re: [OMPI devel] [v1.8] 32-bit c++ build failure with Sun compilers

ooks like it is r28034. I've attached the > patch here - can you please let me know if this fixes the problem? > > > > On Aug 8, 2014, at 11:11 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > A problem Siegmar reported on trunk over a year and a half ago is breaking

Re: [OMPI devel] [v1.8] 32-bit c++ build failure with Sun compilers

- thanks! > > On Aug 9, 2014, at 12:24 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Ralph, > > Yes, that did the trick. > The attached patch applied cleanly to last night's v1.8 tarball > (1.8.2rc4r32480) and I was able to build the C++ bindings on this platform. >

[OMPI devel] [v1.8] build failure with xlc-11.1

Building v1.8 nightly tarball with xlc-11.1 on a ppc64/linux platform: Making all in asm make[2]: Entering directory `/home/hargrov1/OMPI/openmpi-1.8-latest-bluedrop-64-xlc/BLD/opal/asm' CC asm.lo rm -f atomic-asm.S ln -s "../../opal/asm/generated/atomic-local.s" atomic-asm.S CPPAS

[OMPI devel] cosmetic configure nit

One too many 's' characters in the following: checking for asssembly architecture... -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax:

Re: [OMPI devel] [v1.8] build failure with xlc-11.1

does seem to be some flaw in how the atomics are getting built on this configuration. -Paul On Sat, Aug 9, 2014 at 1:22 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > Building v1.8 nightly tarball with xlc-11.1 on a ppc64/linux platform: > > Making all in asm > make[2]: Ent

Re: [OMPI devel] [v1.8] build failure with xlc-11.1

configure/build could produce the reported failure, my test did NOT represent a valid set of conditions. -Paul On Sat, Aug 9, 2014 at 1:29 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > One note regarding my report below: > > I have noticed that autoconf has chosen to use "$src

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

I am on the same page with George here - if it's on the list then support it until its been removed. I happen to have systems to test, I believe, every supported atomics implementation except for DEC Alpha, and so I did test them all. AFAIK ARMv5 is even out-dated as a smartphone platform.

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

atch > I > >> submitted and that Paul validated. > >> What Nathan said he might take a look at is a different method for > >> generating assembly code, one that only supports ARMv7 and later. > >> George. > >> > >> On Mon, Aug 11, 20

Re: [OMPI devel] trunk hang when nodes have similar but private network

I think that in this case one *could* add logic that would disqualify the subnet because every compute node in the job has the SAME address. In fact, any subnet on which two or more compute nodes have the same address must be suspect. If this logic were introduced, the 127.0.0.1 loopback address

[OMPI devel] [1.8.2rc4] build failure with --enable-osx-builtin-atomics

When configured with --enable-osx-builtin-atomics Making all in asm CC asm.lo In file included from /Users/Paul/OMPI/openmpi-1.8.2rc4-macos10.8-x86-clang-atomics/openmpi-1.8.2rc4/opal/asm/asm.c:21:

[OMPI devel] [1.8.2rc4] OSHMEM fortran bindings with bad compilers

The following is NOT a bug report. This is just an observation that may deserve some text in the README. I've reported issues in the past with some Fortran compilers (mostly older XLC and PGI) which either cannot build the "use mpi_f08" module, or cannot correctly link to it (and sometimes this

Re: [OMPI devel] [1.8.2rc4] build failure with --enable-osx-builtin-atomics

Fix confirmed using the nightly tarball (v1.8rc5r32531). -Paul On Wed, Aug 13, 2014 at 6:16 PM, Ralph Castain <r...@open-mpi.org> wrote: > Thanks Paul - fixed in r32530 > > > > On Wed, Aug 13, 2014 at 2:42 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >&g

Re: [OMPI devel] 1.8.4rc4 is out

rify the configure --help message about when OpenSHMEM is > enabled/disabled by default. Thanks to Paul Hargrove for the > suggestion. > - Align pages properly where relevant. Thanks to Paul Hargrove for > identifying the issue. > - Various compiler warning and minor fixes

Re: [OMPI devel] 1.8.4rc4 is out

My testing has additionally passed on IA64 ARM - v5 and v7 MIPS - "32", "n32" and "64" ABIs -Paul On Wed, Aug 13, 2014 at 9:18 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > I have completed testing the majority of the platforms I have access t

Re: [OMPI devel] [OMPI svn] svn:open-mpi r32555 - trunk/opal/mca/btl/scif

Can somebody confirm that configure is adding "-c9x" or "-c99" to CFLAGS with this compiler? If not then r32555 could possibly be reverted in favor of adding the proper compiler flag. Also, I am suspicious of this failure because even without a language-level option pgcc 12.9 and 13.4 compile the

Re: [OMPI devel] Envelope of HINDEXED_BLOCK

> > libtoolize: putting libltdl files in LT_CONFIG_LTDL_DIR, `opal/libltdl'. > libtoolize: `COPYING.LIB' not found in `/usr/share/libtool/libltdl' > autoreconf: libtoolize failed with exit status: 1 > > The error message is from libtoolize about a file missing from the libtool installation

Re: [OMPI devel] 1.8.3rc1 - start your engines

Ralph, I am not sure if I will have time to run my full suite of configurations, including all the PGI, Sun, Intel and IBM compilers on Linux. However, the following non-(Linux/x86-64) platforms have passed: + Linux/{PPC32,PPC64,IA64} + Solaris-10/{SPARC-v8+,SPARC-v9} (Oracle and GNU compilers)

Re: [OMPI devel] CONVERSION TO GITHUB

Jeff, Any instructions for those who have never had Subversion accounts, but do have Trac accounts? You know... the people like me who primarily just make work for others :-) -Paul On Tue, Sep 16, 2014 at 10:34 AM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrote: > Short version >

Re: [OMPI devel] 1.8.3rc1 - start your engines

on Linux. -Paul On Sun, Sep 14, 2014 at 8:55 PM, Ralph Castain <r...@open-mpi.org> wrote: > Your contributions are always appreciated, Paul - thanks! > > On Sep 13, 2014, at 7:51 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Ralph, > > I am not sure if I wi

Re: [OMPI devel] CONVERSION TO GITHUB

t; Not really. > > One minor point: you'll need a Github account to file Github issues (i.e., > what's replacing Trac tickets) and/or use the code commenting tools. > > > > On Sep 16, 2014, at 2:33 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > Jeff, >

Re: [OMPI devel] CONVERSION TO GITHUB

On Wed, Sep 17, 2014 at 8:06 AM, Jeff Squyres (jsquyres) wrote: > I actually have the mapping already. The *only* ID that is preserved > between the two will be who the ticket is assigned to. You sent out email asking for SVN -> github ID mapping, but did NOT ask about

Re: [OMPI devel] Bitbucket vs. GitHub (was: Conversion to GitHub: POSTPONED)

) are at Github. > > 2. I just sent a mail to Github support asking them if they plan to > support per-branch push ACLs. I don't know if they'll be able to give a > direct answer, but it's worth asking. > > > > It would be a little weird to span Github and Bitbucket, but th

Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

I agree with George that zeroing memory only in the debug builds could hide bugs, and thus would want to see the debug and non-debug builds have the same behavior (both malloc or both calloc). So, I also agree this looks initially like a hard choice. What about using malloc() in non-debug builds

Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

ng calloc() when --with-valgrind > is specified on the command line? > > I.e., don't tie it to debug builds, but to valgrind-enabled builds? > > > On Oct 3, 2014, at 6:11 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > I agree with George that zeroing memory

Re: [OMPI devel] Fwd: Open MPI 1.8: link problem when Fortran+C+Platform LSF

I know of two possibilities: 1) I cannot be certain but since the message concerns a PC-relative addressing mode, it is possible that something needs to be compiled with -fPIC to fix the issue. See if adding that option to any of the mpicc commands helps. 2) Try adding ONE of "-ll", "-lfl" or

Re: [OMPI devel] Open MPI 1.8: link problem when Fortran+C+Platform LSF

gt; Schinkelstrasse 2, Room 222a > D-52062 Aachen > > Phone +49 (0)241 80 99932 > fri...@cats.rwth-aachen.de > http://www.cats.rwth-aachen.de > > On 18.10.2014, at 02:24, Paul Hargrove <phhargr...@lbl.gov> wrote: > > I know of two possibilities: > >

Re: [OMPI devel] Deprecated call in sharedfp framework

I can shed some light on these warnings. sem_init() and sem_destroy() are POSIX-defined interfaces for UNNAMED semaphores. There are also POSX interfaces, sem_{open,close,unlink}(), that operate on NAMED semaphores. See for more info:

Re: [OMPI devel] errno and reentrance

On Mon, Oct 27, 2014 at 2:42 AM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: [...] > Paul, since you have access to many platforms, could you please run this > test with and without -D_REENTRANT / -D_THREAD_SAFE > and tell me where the program produces incorrect behaviour (output

Re: [OMPI devel] errno and reentrance

27, 2014 at 2:48 AM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > Thanks Paul ! > > Gilles > > On 2014/10/27 18:47, Paul Hargrove wrote: > > On Mon, Oct 27, 2014 at 2:42 AM, Gilles Gouaillardet > <gilles.gouaillar...@iferc.org> wrote

Re: [OMPI devel] configure.m4 for pmix/s1 and pmix/s2 question

On Tue, Oct 28, 2014 at 11:53 AM, Howard Pritchard wrote: > >> We may no longer require those as you have separated the Cray check out, >> but the original problem is that we would pickup the Slurm components on >> the Cray because we would find pmi.h >> >> Oh, I forgot

Re: [OMPI devel] configure.m4 for pmix/s1 and pmix/s2 question

/opt/cray/pmi/default/include/pmi_cray.h cray-libpmi-devel-5.0.5-1..10300.134.8.ari -Paul On Tue, Oct 28, 2014 at 12:02 PM, Ralph Castain <r...@open-mpi.org> wrote: > > On Oct 28, 2014, at 11:59 AM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > On Tue, Oct 2

Re: [OMPI devel] configure.m4 for pmix/s1 and pmix/s2 question

On Tue, Oct 28, 2014 at 12:20 PM, Ralph Castain <r...@open-mpi.org> wrote: > On Oct 28, 2014, at 12:17 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Ralph, > > The Cray's at NERSC have *both* pmi_cray.h and pmi.h (and pmi2.h as well). > > > I

Re: [OMPI devel] configure.m4 for pmix/s1 and pmix/s2 question

are suppose to include > all dependencies on headers files, libs, etc. from other cay packages. > > Howard > > > > > 2014-10-28 13:20 GMT-06:00 Ralph Castain <r...@open-mpi.org>: > >> >> On Oct 28, 2014, at 12:17 PM, Paul Hargrove <phhargr...@lbl.gov

Re: [OMPI devel] Error: undefined reference `__builtin_va_gparg1'

Amit, You appear to be mixing PGI and GNU compilers, as shown by the "g++" in the final portion of your output. You must configure Open MPI with all compilers (C, C++ and Fortran) from the same "family". -Paul On Wed, Oct 29, 2014 at 1:11 PM, Kumar, Amit wrote: > Dear

Re: [OMPI devel] OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-198-g68bec0a

On Mon, Nov 3, 2014 at 8:29 AM, Dave Goodell (dgoodell) wrote: > > btw, is there a push option to abort if that would make github history > non linear ? > > No, not really. There are some options to "pull" to prevent you from > creating a merge commit, but the fix when you

Re: [OMPI devel] OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-198-g68bec0a

IIRC it was not possible to merge with a dirty tree with git 1.7. So, Dave, you may have been bitten in those dark days. -Paul On Mon, Nov 3, 2014 at 8:49 AM, Dave Goodell (dgoodell) wrote: > On Nov 3, 2014, at 10:41 AM, Jed Brown wrote: > > > "Dave

  1   2   3   4   5   6   7   8   9   >