Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

hummm i intentionally did not swap the two 32 bits (!) from the top level, what we have is : typedef struct { union { uint64_t opal; struct { uint32_t jobid; uint32_t vpid; } orte; } meta_process_name_t; OPAL is agnostic about jobid and vpid. jobid

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

Ah yes, so it is - sorry I missed that last test :-/ On Aug 5, 2014, at 10:50 AM, George Bosilca wrote: > The code committed by Gilles is correctly protected for big endian > (https://svn.open-mpi.org/trac/ompi/changeset/32425). I was merely pointing > out that I think he

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

Gilles, I have not tested your patch. I've only read it. It looks like it could work, except that libopen-rte.a depends on libsocket and libnsl on Solaris. So, one probably needs to add $LIBS to the ORTE wrapper libs as well. Additionally,if your approach is the correct one, then I think one

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

Thanks to Paul help all the inlined atomics have been tested. The new patch is attached below. However, this only fixes the inline atomics, all those generated from the *.asm files have not been updated. Any volunteer?  George. atomics.patch Description: Binary data On Aug 1, 2014, at 18:09 ,

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

The code committed by Gilles is correctly protected for big endian ( https://svn.open-mpi.org/trac/ompi/changeset/32425). I was merely pointing out that I think he should also swap the 2 32 bits in his implementation. George. On Tue, Aug 5, 2014 at 1:32 PM, Ralph Castain

Re: [OMPI devel] canceling buffered send request with pml/cm

Yossi, I think you raised an interesting corner-case, and a possible bug in the MTL implementation. As the request is marked as complete by the CM/PML the cancel should never succeed. As the CM/PML is forcing the completion on all bend requests, it should also enforce that all completed

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

On Aug 5, 2014, at 10:23 AM, George Bosilca wrote: > On Tue, Aug 5, 2014 at 1:15 PM, Ralph Castain wrote: > Hmmm...wouldn't that then require that you know (a) the other side is little > endian, and (b) that you are on a big endian? Otherwise, you wind

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

On Tue, Aug 5, 2014 at 1:15 PM, Ralph Castain wrote: > Hmmm...wouldn't that then require that you know (a) the other side is > little endian, and (b) that you are on a big endian? Otherwise, you wind up > with the same issue in reverse, yes? > This is similar to the 32 bits

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

Hmmm...wouldn't that then require that you know (a) the other side is little endian, and (b) that you are on a big endian? Otherwise, you wind up with the same issue in reverse, yes? In the ORTE methods, we explicitly set the fields (e.g., jobid = ntohl(remote-jobid)) to get around this

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

Technically speaking, converting a 64 bits to a big endian representation requires the swap of the 2 32 bits parts. So the correct approach would have been: uint64_t htonll(uint64_t v) { return uint64_t)ntohl(n)) << 32 | (uint64_t)ntohl(n >> 32)); } George. On Tue, Aug 5, 2014 at

Re: [OMPI devel] oshmem enabled by default

Sounds like clearer language - done! On Aug 4, 2014, at 7:58 PM, Paul Hargrove wrote: > Since "disabled by default" is just part of a macro argument we can say > anything we want. > I propose the following: > > Index: config/oshmem_configure_options.m4 >

Re: [OMPI devel] minor atomics nit

Done - thanks! On Aug 4, 2014, at 7:15 PM, Paul Hargrove wrote: > 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

Re: [OMPI devel] 1.8.2rc3 cosmetic issues in configure

Got these cleaned up - will commit and CMR Thanks! Ralph On Aug 4, 2014, at 12:47 AM, Paul Hargrove wrote: > 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

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

FWIW: that's exactly how we do it in ORTE On Aug 4, 2014, at 10:25 PM, Gilles Gouaillardet wrote: > George, > > i confirm there was a problem when running on an heterogeneous cluster, > this is now fixed in r32425. > > i am not convinced i chose the most

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

Here is a patch that has been minimally tested. this is likely an overkill (at least when dynamic libraries can be used), but it does the job so far ... Cheers, Gilles On 2014/08/05 16:56, Gilles Gouaillardet wrote: > from libopen-pal.la : > dependency_libs=' -lrdmacm -libverbs -lscif -lnuma

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

from libopen-pal.la : dependency_libs=' -lrdmacm -libverbs -lscif -lnuma -ldl -lrt -lnsl -lutil -lm' i confirm mpicc fails linking but FWIT, using libtool does work (!) could the bug come from the mpicc (and other) wrappers ? Gilles $ gcc -g -O0 -o hw /csc/home1/gouaillardet/hw.c

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 wrote: > On 08/05/2014 02:40 AM, Paul Hargrove wrote: > >> I

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

On 08/05/2014 02:40 AM, Paul Hargrove wrote: 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

Re: [OMPI devel] OMPI devel] trunk compilation errors in jenkins

George, i confirm there was a problem when running on an heterogeneous cluster, this is now fixed in r32425. i am not convinced i chose the most elegant way to achieve the desired result ... could you please double check this commit ? Thanks, Gilles On 2014/08/02 0:14, George Bosilca wrote: >