Opps, my compiler didn’t catch that. Will fix that now.
> On Jun 2, 2016, at 7:07 PM, George Bosilca wrote:
>
> Nathan,
>
> I see a lot of [for once valid] complains from clang regarding the last UGNI
> related commit. More precisely the MCA_BTL_ATOMIC_SUPPORTS_FLOAT value is too
> large with
Nathan,
I see a lot of [for once valid] complains from clang regarding the last
UGNI related commit. More precisely the MCA_BTL_ATOMIC_SUPPORTS_FLOAT value
is too large with respect to the fact that ISO C restricts a enum to int.
Can we pack the enums ?
George.
../../../../../ompi/opal/mca/btl
Sure, but they mostly look similar.
George.
(lldb) thread list
Process 76811 stopped
thread #1: tid = 0x272b40e, 0x7fff93306de6
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP
thread #2: tid = 0x272b40f, 0x7fff93306de6
l
George --
You might want to get bt's from *all* the threads...?
> On Jun 2, 2016, at 5:31 PM, George Bosilca wrote:
>
> The timeout never triggers and when I attach to the mpirun process I see an
> extremely strange stack:
>
> (lldb) bt
> * thread #1: tid = 0x272b40e, 0x7fff93306de6
> l
The timeout never triggers and when I attach to the mpirun process I see an
extremely strange stack:
(lldb) bt
* thread #1: tid = 0x272b40e, 0x7fff93306de6
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x7fff9330
The osc hang is fixed by a PR to fix bugs in start in cm and ob1. See #1729.
-Nathan
> On Jun 2, 2016, at 5:17 AM, Gilles Gouaillardet
> wrote:
>
> fwiw,
>
> the onsided/c_fence_lock test from the ibm test suite hangs
>
> (mpirun -np 2 ./c_fence_lock)
>
> i ran a git bisect and it incrimina
fwiw,
the onsided/c_fence_lock test from the ibm test suite hangs
(mpirun -np 2 ./c_fence_lock)
i ran a git bisect and it incriminates commit
b90c83840f472de3219b87cd7e1a364eec5c5a29
commit b90c83840f472de3219b87cd7e1a364eec5c5a29
Author: bosilca
List-Post: devel@lists.open-mpi.org
Date: Tue
The branch will be merged once we know make check succeeds on arm64 with
—disable-builtin-atomics. Just waiting on that testing.
-Nathan
> On Jun 1, 2016, at 10:22 PM, Sreenidhi Bharathkar Ramesh
> wrote:
>
> Thank you for the response.
>
> Nathan,
> Sure, we will try out your branch and let
Thank you for the response.
Nathan,
Sure, we will try out your branch and let you know. Any idea when it is
likely to be pulled into master ?
I presume that our changes, if any, will need to be on top of these changes.
Jeff,
A few clarifications please:
> a) run MTT regularly and submit the re
