1
1
Граф коммитов

13 Коммитов

Автор SHA1 Сообщение Дата
Ralph Castain
869041f770 Purge whitespace from the repo 2015-06-23 20:59:57 -07:00
Gilles Gouaillardet
d9c490cf9f refactor opal_bitmap_get_string
make it more efficient and fix CID 71992 (dead code)
2015-06-17 11:17:53 +09:00
Ralph Castain
811f3d0665 Remove unused vars and actually test the indexed array member in the bitmap class
This commit was SVN r32004.
2014-06-14 03:18:24 +00:00
George Bosilca
13252206ad Correctly handle the case where we restrict the size to INT_MAX.
This commit was SVN r32003.
2014-06-13 21:32:46 +00:00
George Bosilca
fbe69808f2 A faster implementation of the OPAL_BITMAP. The corresponding
test has also been updated.

This commit was SVN r32001.
2014-06-13 21:15:35 +00:00
Ralph Castain
c33219a51b Extend the bitmap API a bit to provide a test if all bits zero
This commit was SVN r28486.
2013-05-14 03:34:57 +00:00
Josh Hursey
f7c66f54b6 Add a pair of functions to count the number of set/unset bits in an opal_bitmap.
I found this useful on a branch, and thought others might as well.

This commit was SVN r26171.
2012-03-21 14:16:45 +00:00
Josh Hursey
8cd5280299 Some assorted opal_bitmap extensions
* Protect the '->bitmap' field if init() is called more than once [it shouldn't be, but if it is then this avoids a memory leak].
 * Some new functions
   * opal_bitmap_bitwise_and_inplace
   * opal_bitmap_bitwise_or_inplace
   * opal_bitmap_bitwise_xor_inplace
   * opal_bitmap_are_different
   * opal_bitmap_get_string

Adding these features to the trunk so others have access to them if they need them. A couple off trunk branches make use of them.

This commit was SVN r24767.
2011-06-09 14:43:54 +00:00
Ralph Castain
db1b07c02c In multiple places in the code base, we expect opal_bitmap_is_set_bit to return either true or false...not a negative error code. If the index is out of range, this is effectively a "false" condition as the bit was clearly not set by the program.
This revision is consistent with how the function was called in the OMPI code base. Will fix the test to match.

This commit was SVN r22544.
2010-02-03 19:45:22 +00:00
Rainer Keller
b572dc3591 - As discussed revert r21330, Fortran-configure info should
not end up in OPAL
 - Will post an updated patch for the OMPI_ALIGNMENT_ parts (within C).

This commit was SVN r21342.

The following SVN revision numbers were found above:
  r21330 --> open-mpi/ompi@95596d1814
2009-06-01 19:02:34 +00:00
Rainer Keller
95596d1814 - Move alignment and size output generated by configure-tests
into the OPAL namespace, eliminating cases like opal/util/arch.c
   testing for ompi_fortran_logical_t.
   As this is processor- and compiler-related information
   (e.g. does the compiler/architecture support REAL*16)
   this should have been on the OPAL layer.
 - Unifies f77 code using MPI_Flogical instead of opal_fortran_logical_t

 - Tested locally (Linux/x86-64) with mpich and intel testsuite
   but would like to get this week-ends MTT output


 - PLEASE NOTE: configure-internal macro-names and
   ompi_cv_ variables have not been changed, so that
   external platform (not in contrib/) files still work.

This commit was SVN r21330.
2009-05-30 15:54:29 +00:00
Rainer Keller
811f2bd9b4 - As discussed on RFC, move the ompi_bitmap to the
opal layer.
   Add a check against a maximum (actually get rid of ifs internally to
   opal_bitmap.c) -- the functionality to set the current maximum size
   opal_bitmap_set_max_size() is currently only used in attribute.c
   to set the maximum OMPI_FORTRAN_HANDLE_MAX...

   Tested on linux/x86-64 with intel-tests with all_tests_no_perf_f
   run with 6 procs.
   Let's look into MTT as well...

This commit was SVN r20708.
2009-03-03 22:25:13 +00:00
Ralph Castain
15c47a2473 Revise the daemon collective system to handle comm_spawn patterns that cross into new nodes that are not direct children on the routing tree of the HNP.
Refers to ticket #1548. Although this appears to fix the problem, the ticket will be held open pending further test prior to transition to the 1.3 branch.

This commit was SVN r19674.
2008-10-02 20:08:27 +00:00