On Tue, Feb 7, 2012 at 7:54 PM, Paul H. Hargrove wrote:
[snip]
> Of those 54:
> + 47 require nothing "extra" (just --prefix, CC & friends, and CFLAGS &
> friends for non-default ABIs)
>
[snip]
I found 5 more, making a total of 52 out of 59 configs that PASS with no
"extra" steps or configure opt
Add 3 more to the PASS list:
linux/x86-64 open64 w/ -m32
openbsd5/amd64 llvm-gcc-2.9 (C and C++, no FORTAN)
openbsd5/i386 llvm-gcc-2.9 (C and C++, no FORTAN)
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department
On 2/7/2012 4:25 PM, Paul H. Hargrove wrote:
On 2/7/2012 8:59 AM, Jeff Squyres wrote:
This fixes all known issues.
Well, not quite...
I've SUCCESSFULLY retested 44 out of the 55 cpu/os/compiler/abi
combinations currently on my list.
I expect 9 more by the end of the day (the older/slower
On 2/7/2012 9:57 PM, Paul H. Hargrove wrote:
On 2/7/2012 2:37 PM, Paul H. Hargrove wrote:
+ "make check" fails atomics tests using GCCFSS-4.0.4 compilers on
Solaris10/SPARC
Originally reported in:
http://www.open-mpi.org/community/lists/devel/2012/01/10234.php
This is a matter of the Sun/O
On 2/8/2012 3:25 AM, TERRY DONTJE wrote:
+ Building w/ Solaris Studio 12.2 or 12.3 on Linux x86-64, with
"-m32" required setting LD_LIBRARY_PATH.
Can the LD_LIBRARY_PATH be substituted with a rpath change in LDFLAGS
of the build?
Terry sent more specific instructions for that offlist, and I
Some of you may have already noticed: As the v1.5 RM, I took the executive
decision this morning to bump up the tarball versions of the GNU Autotools on
the v1.5 branch this morning. Some of you may remember that we have a policy
of not changing autotools versions in a release series unless we
On 2/8/2012 11:14 AM, Paul H. Hargrove wrote:
On 2/8/2012 3:25 AM, TERRY DONTJE wrote:
+ Building w/ Solaris Studio 12.2 or 12.3 on Linux x86-64, with
"-m32" required setting LD_LIBRARY_PATH.
Can the LD_LIBRARY_PATH be substituted with a rpath change in LDFLAGS
of the build?
Terry sent mo
All -
With r25865, the trunk now has support for the MPI-3 matched probe
functionality. Currently, all PMLs other than OB1 will throw a not
implemented error when mprobe, improbe, mrecv, or imrecv are called. I
will adding support to CM for matched probe (which will likely require
changes to the
Hi,
I've noticed that the self btl does not do any locking. It has one
lock defined but its not actually used anywhere.
So I'm just wondering if that is an oversight or if there is a reason
that we know for sure that there will never be concurrent access
to that particular btl with threads enable
On Feb 8, 2012, at 5:57 PM, Christopher Yeoh wrote:
> I've noticed that the self btl does not do any locking. It has one
> lock defined but its not actually used anywhere.
>
> So I'm just wondering if that is an oversight or if there is a reason
> that we know for sure that there will never be co
The self BTL is different from any other BTL. Any memcpy operation done by this
BTL is automatically protected behind the matching logic, and therefore does
not require extra thread safety protection. A mutex in the self BTL is mostly a
copy/paste mistake.
george.
On Feb 8, 2012, at 17:57 ,
On Feb 8, 2012, at 8:58 PM, George Bosilca wrote:
> The self BTL is different from any other BTL. Any memcpy operation done by
> this BTL is automatically protected behind the matching logic, and therefore
> does not require extra thread safety protection. A mutex in the self BTL is
> mostly a
3 anonymous accesses and 12 developer accesses from 2010-11-25 till today,
that's what the mpiJava project hosted on sourceforge got. It tends to say
something about the need for such a binding now, the size of the community
requiring such a binding and about the support Open MPI should throw to
On Wed, 8 Feb 2012 20:58:52 -0500
George Bosilca wrote:
> The self BTL is different from any other BTL. Any memcpy operation
> done by this BTL is automatically protected behind the matching
> logic, and therefore does not require extra thread safety protection.
> A mutex in the self BTL is mostl
Indeed. The lists you pinpoint at are used via the OMPI_FREE_LIST_GET macro,
which is based on atomic operations. We're all safe on that front.
Even if multiple threads call the self BTL functions simultaneously we are safe
due to the MPI semantics (the matching logic is protected, it can succee
I agree - we do have better things to do than argue about things that have no
impact on anyone not choosing to use them.
If you had read the RFC, you would have seen that the Hadoop businesses are
unwilling to trust their future to a 3rd party bolt-on that already shows
bit-rot. Hence, the desi
16 matches
Mail list logo
