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 inco
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, I
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 is
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 WORK-
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
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 co
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
> gen
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 i
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 svn-full]
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: https://svn.open-mpi.org/tra
Fair point, though -- Open PBS has bit-rotted a lot since then. It *should*
work with Open MPI, but I don't think anyone has actually tested with it in
years. I'll remove it.
On Feb 23, 2012, at 10:53 PM, Ralph Castain wrote:
> OpenPBS, PBS Pro, and Torque are all identical from our perspecti
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
12 matches
Mail list logo
