Re: [OMPI devel] 1.5.5rc2 atomics fail w/ xlc-9

OK, this is NOT an issue for v1.5.5, IMHO. I was mistaken about the ppc atomics having an error that could impact builds with gcc. The problems I've seen with xlc-9.0 turn out to be just a plain xlc bug. When the asm takes as an argument the address of a signed 32-bit int, the compiler is

[hwloc-devel] Create success (hwloc r1.3.3a1r4352)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.3.3a1r4352 Start time: Fri Feb 24 21:06:58 EST 2012 End time: Fri Feb 24 21:09:55 EST 2012 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc r1.4.1rc2r4353)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.4.1rc2r4353 Start time: Fri Feb 24 21:04:12 EST 2012 End time: Fri Feb 24 21:06:58 EST 2012 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc r1.5a1r4350)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.5a1r4350 Start time: Fri Feb 24 21:01:01 EST 2012 End time: Fri Feb 24 21:04:12 EST 2012 Your friendly daemon, Cyrador

Re: [OMPI devel] 1.5.5rc2 atomics fail w/ xlc-9

Hmm, I was certain I knew what was wrong, but the tests still fail. Nobody should hold their breath waiting for my patches, but I am still investigating. *IF* I can determine that I am right about the asm allowing gcc to generate bad code then I think this is important for 1.5.5. Otherwise,

[OMPI devel] 1.5.5rc2 atomics fail w/ xlc-9

I see now why I get "check" failures from the opal atomics w/ XLC-9.0. The inline asm is mildly incorrect and I am actually surprised gcc didn't produce bad code. Patch(es) will be sent ASAP as I think this should be fixed for 1.5.5. -Paul On 2/23/2012 8:24 PM, Paul H. Hargrove wrote: This

Re: [OMPI devel] 1.5.5rc2

Sorry, I just realized there was fair amount of context missing from my previous post: The fix that Mattias committed as r26042 on the trunk is intended to correct the improper auto-detection of BG/P (or /L) when one is building for the front-end. My suggested --with-platform=linux is a

Re: [OMPI devel] 1.5 supported systems

I dont see any problem with indicating that Open MPI hasn't (knowingly) broken compatibility with Open PBS (which we all agree is not changing). Some of us run our own version of PBS derived from Open PBS. If the Torque and PBSPro tm interfaces were ever changed and Open MPI was changed to only

Re: [OMPI devel] 1.5.5rc2

Christopher, Just wanted to note that when you build like this on the BG/P front end, VT is detecting the BG/P environment and so trying to build for the BG/P compute node, meanwhile OMPI is building for the front-end node. (Somebody correct me if I've misunderstood). So, you may want to

Re: [hwloc-devel] hwloc_alloc_membind

Karl Napf, le Fri 24 Feb 2012 14:45:26 +0100, a écrit : > Thanks a lot, Samuel. BTW the documentation says that > hwloc_alloc_membind and hwloc_alloc_membind_nodeset return -1 on > error, but this should be NULL. Indeed! Thanks, Samuel

Re: [OMPI devel] 1.5.5rc2

Thanks for the hint! This issue is fixed by r26042 (CMR #3037). Matthias On Friday 24 February 2012 05:24:26 Paul H. Hargrove wrote: > This is consistent with my findings w/ XLC (mostly on BG/L and BG/P > front end nodes). > None of the 7.0, 8.0, 9.0 or 11.1 versions of XLC I tested could >

Re: [hwloc-devel] hwloc_alloc_membind

Thanks a lot, Samuel. BTW the documentation says that hwloc_alloc_membind and hwloc_alloc_membind_nodeset return -1 on error, but this should be NULL. Regards Karl 2012/2/24 Samuel Thibault : > Karl Napf, le Fri 24 Feb 2012 13:04:58 +0100, a écrit : >> What surprises

Re: [hwloc-devel] hwloc_alloc_membind

Karl, I'll release hwloc 1.4.1rc2 with Samuel's changes on Monday. If you need the fix earlier, you can apply https://svn.open-mpi.org/trac/hwloc/changeset/4345 or checkout svn branch v1.4 or use the nightly build that will be updated tomorrow early morning at

Re: [hwloc-devel] hwloc_alloc_membind

Karl Napf, le Fri 24 Feb 2012 13:04:58 +0100, a écrit : > What surprises me is that the result of the call to > hwloc_fix_membind_cpuset in line 534 of bind.c is negated, even though > hwloc_fix_membind_cpuset returns 0 on success. Might this be a bug? Oops, indeed. > 2. In another use case I

[hwloc-devel] hwloc_alloc_membind

Hi, I've got a problem and a question regarding hwloc_alloc_membind (I'm using hwloc V 1.4): 1. I want to allocate memory near a particular CPU by the call hwloc_alloc_membind(topology, len, cpuset, HWLOC_MEMBIND_BIND, HWLOC_MEMBIND_STRICT). I tried this on two Linux machines (single-core,

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r26039

Ah, I see -- it was already there before this commit. FWIW: you might want to move all those CUDA m4 tests into a separate file, like opal/config/opal_check_cuda (or ompi, if CUDA is only used in the ompi layer?). On Feb 24, 2012, at 6:11 AM, Rolf vandeVaart wrote: > Hi Jeff: > > It is set

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r26039

Hi Jeff: It is set in opal/config/opal_configure_options.m4 >-Original Message- >From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] >On Behalf Of Jeffrey Squyres >Sent: Friday, February 24, 2012 6:07 AM >To: de...@open-mpi.org >Subject: Re: [OMPI devel] [OMPI

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r26039

Rolf -- In looking at configure.m4, where does $CUDA_SUPPORT_41 get set? AS_IF([test "x$CUDA_SUPPORT_41" = "x1"] On Feb 23, 2012, at 9:13 PM, ro...@osl.iu.edu wrote: > Author: rolfv > Date: 2012-02-23 21:13:33 EST (Thu, 23 Feb 2012) > New Revision: 26039 > URL:

Re: [OMPI devel] 1.5 supported systems

I agree w/ Jeff that we really should only enumerate "bad" compilers (blacklist rather than whitelist). However, as Larry points out, "gcc" is not as clearly defined as it once was. Currently I know of both Apple and Oracle shipping compilers with the gcc front-end and "other" backend (llvm from