ports/openmpi
ports/openmpi
1
1
Форкнуть 0
Код Релизы Активность
openmpi/ompi/mca/op/base/op_base_functions.c

1545 строки
55 KiB
C
Исходник Обычный вид История

Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
/* -*- Mode: C; c-basic-offset:4 ; indent-tabs-mode:nil -*- */
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
/*
Shame on me for not looking at the expanded collective datatype tables for the C++ bindings in MPI-2 p276-278 to see that MPI_BOOL should work with MPI_LAND, MPI_LOR, and MPI_LXOR. Thanks to Andy Selle for pointing this out. This commit was SVN r9200.
2006-03-04 18:35:33 +00:00
* Copyright (c) 2004-2006 The Trustees of Indiana University and Indiana
Update the copyright notices for IU and UTK. This commit was SVN r7999.
2005-11-05 19:57:48 +00:00
* University Research and Technology
* Corporation. All rights reserved.
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
* Copyright (c) 2004-2010 The University of Tennessee and The University
Update the copyright notices for IU and UTK. This commit was SVN r7999.
2005-11-05 19:57:48 +00:00
* of Tennessee Research Foundation. All rights
* reserved.
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
* Copyright (c) 2004-2007 High Performance Computing Center Stuttgart,
Add HLRS copyright This commit was SVN r3665.
2004-11-28 20:09:25 +00:00
* University of Stuttgart. All rights reserved.
Add UC copyright This commit was SVN r5009.
2005-03-24 12:43:37 +00:00
* Copyright (c) 2004-2005 The Regents of the University of California.
* All rights reserved.
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
* Copyright (c) 2006-2014 Cisco Systems, Inc. All rights reserved.
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
* Copyright (c) 2013 Los Alamos National Security, LLC. All rights
* reserved.
First cut at copyrights: IU, UTK, and some OSU. LANL and HLRS still pending. This commit was SVN r3655.
2004-11-22 01:38:40 +00:00
* $COPYRIGHT$
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
*
First cut at copyrights: IU, UTK, and some OSU. LANL and HLRS still pending. This commit was SVN r3655.
2004-11-22 01:38:40 +00:00
* Additional copyrights may follow
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
*
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
* $HEADER$
*/
First pass of lam -> ompi conversion This commit was SVN r1191.
2004-06-07 15:33:53 +00:00
#include "ompi_config.h"
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
- Add #if protection around non-portable system .h files - Add #include "ompi_config.h" to all .c files, and ensure that it's the first #included file - remove a few useless #if HAVE_CONFIG_H checks This commit was SVN r3229.
2004-10-20 01:03:09 +00:00
#ifdef HAVE_SYS_TYPES_H
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#include <sys/types.h>
- Add #if protection around non-portable system .h files - Add #include "ompi_config.h" to all .c files, and ensure that it's the first #included file - remove a few useless #if HAVE_CONFIG_H checks This commit was SVN r3229.
2004-10-20 01:03:09 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#include "ompi/mca/op/op.h"
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*
* Since all the functions in this file are essentially identical, we
* use a macro to substitute in names and types. The core operation
* in all functions that use this macro is the same.
*
* This macro is for (out op in).
*/
#define OP_FUNC(name, type_name, type, op) \
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
static void ompi_op_base_2buff_##name##_##type_name(void *in, void *out, int *count, \
struct ompi_datatype_t **dtype, \
struct ompi_op_base_module_1_0_0_t *module) \
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
{ \
Cosmetic changes: * Update to 4 space tabs where relevant (and some irrelevant white space changes) * Move a few constants to the left of !=/== * Add a few {}'s are one line blocks * Use BEGIN/END_C_DECLS * Change /**< to /** in a few places This commit was SVN r20177.
2008-12-31 14:50:54 +00:00
int i; \
type *a = (type *) in; \
type *b = (type *) out; \
for (i = 0; i < *count; ++i) { \
*(b++) op *(a++); \
} \
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
}
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*
* Since all the functions in this file are essentially identical, we
* use a macro to substitute in names and types. The core operation
* in all functions that use this macro is the same.
*
* This macro is for (out = op(out, in))
*/
#define FUNC_FUNC(name, type_name, type) \
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
static void ompi_op_base_2buff_##name##_##type_name(void *in, void *out, int *count, \
struct ompi_datatype_t **dtype, \
struct ompi_op_base_module_1_0_0_t *module) \
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
{ \
Cosmetic changes: * Update to 4 space tabs where relevant (and some irrelevant white space changes) * Move a few constants to the left of !=/== * Add a few {}'s are one line blocks * Use BEGIN/END_C_DECLS * Change /**< to /** in a few places This commit was SVN r20177.
2008-12-31 14:50:54 +00:00
int i; \
type *a = (type *) in; \
type *b = (type *) out; \
for (i = 0; i < *count; ++i) { \
*(b) = current_func(*(b), *(a)); \
++b; \
++a; \
} \
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
}
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
/*
* Since all the functions in this file are essentially identical, we
* use a macro to substitute in names and types. The core operation
* in all functions that use this macro is the same.
*
* This macro is for minloc and maxloc
*/
#define LOC_STRUCT(type_name, type1, type2) \
typedef struct { \
Cosmetic changes: * Update to 4 space tabs where relevant (and some irrelevant white space changes) * Move a few constants to the left of !=/== * Add a few {}'s are one line blocks * Use BEGIN/END_C_DECLS * Change /**< to /** in a few places This commit was SVN r20177.
2008-12-31 14:50:54 +00:00
type1 v; \
type2 k; \
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
} ompi_op_predefined_##type_name##_t;
#define LOC_FUNC(name, type_name, op) \
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
static void ompi_op_base_2buff_##name##_##type_name(void *in, void *out, int *count, \
struct ompi_datatype_t **dtype, \
struct ompi_op_base_module_1_0_0_t *module) \
{ \
int i; \
ompi_op_predefined_##type_name##_t *a = (ompi_op_predefined_##type_name##_t*) in; \
ompi_op_predefined_##type_name##_t *b = (ompi_op_predefined_##type_name##_t*) out; \
for (i = 0; i < *count; ++i, ++a, ++b) { \
if (a->v op b->v) { \
b->v = a->v; \
b->k = a->k; \
} else if (a->v == b->v) { \
b->k = (b->k < a->k ? b->k : a->k); \
} \
} \
}
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Max
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) > (b) ? (a) : (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(max, int8_t, int8_t)
FUNC_FUNC(max, uint8_t, uint8_t)
FUNC_FUNC(max, int16_t, int16_t)
FUNC_FUNC(max, uint16_t, uint16_t)
FUNC_FUNC(max, int32_t, int32_t)
FUNC_FUNC(max, uint32_t, uint32_t)
FUNC_FUNC(max, int64_t, int64_t)
FUNC_FUNC(max, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC(max, fortran_integer, ompi_fortran_integer_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC(max, fortran_integer1, ompi_fortran_integer1_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC(max, fortran_integer2, ompi_fortran_integer2_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC(max, fortran_integer4, ompi_fortran_integer4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC(max, fortran_integer8, ompi_fortran_integer8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC(max, fortran_integer16, ompi_fortran_integer16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Floating point */
FUNC_FUNC(max, float, float)
FUNC_FUNC(max, double, double)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
FUNC_FUNC(max, long_double, long double)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
FUNC_FUNC(max, fortran_real, ompi_fortran_real_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
FUNC_FUNC(max, fortran_double_precision, ompi_fortran_double_precision_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
FUNC_FUNC(max, fortran_real2, ompi_fortran_real2_t)
- Support for opt. MPI_REAL2 (who has that?) to make checks for MPI-implementations fail in the right way ,-] - check in configure.ac - BINARY INCOMPATIBLE change to mpif-common.h (if implemented the *right* way) Actually OMPI_F90_CHECK takes two arguments, not three. - Only have corresponding C-Type, if the opt. Fortran type is really supported, Otherwise pass ompi_mpi_unavailable to DECLARE_MPI_SYNONYM_DDT; - Reviewed by George and Jeff This commit was SVN r15133.
2007-06-19 05:03:11 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
FUNC_FUNC(max, fortran_real4, ompi_fortran_real4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
FUNC_FUNC(max, fortran_real8, ompi_fortran_real8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
FUNC_FUNC(max, fortran_real16, ompi_fortran_real16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Min
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) < (b) ? (a) : (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(min, int8_t, int8_t)
FUNC_FUNC(min, uint8_t, uint8_t)
FUNC_FUNC(min, int16_t, int16_t)
FUNC_FUNC(min, uint16_t, uint16_t)
FUNC_FUNC(min, int32_t, int32_t)
FUNC_FUNC(min, uint32_t, uint32_t)
FUNC_FUNC(min, int64_t, int64_t)
FUNC_FUNC(min, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC(min, fortran_integer, ompi_fortran_integer_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC(min, fortran_integer1, ompi_fortran_integer1_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC(min, fortran_integer2, ompi_fortran_integer2_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC(min, fortran_integer4, ompi_fortran_integer4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC(min, fortran_integer8, ompi_fortran_integer8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC(min, fortran_integer16, ompi_fortran_integer16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Floating point */
FUNC_FUNC(min, float, float)
FUNC_FUNC(min, double, double)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
FUNC_FUNC(min, long_double, long double)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
FUNC_FUNC(min, fortran_real, ompi_fortran_real_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
FUNC_FUNC(min, fortran_double_precision, ompi_fortran_double_precision_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
FUNC_FUNC(min, fortran_real2, ompi_fortran_real2_t)
- Support for opt. MPI_REAL2 (who has that?) to make checks for MPI-implementations fail in the right way ,-] - check in configure.ac - BINARY INCOMPATIBLE change to mpif-common.h (if implemented the *right* way) Actually OMPI_F90_CHECK takes two arguments, not three. - Only have corresponding C-Type, if the opt. Fortran type is really supported, Otherwise pass ompi_mpi_unavailable to DECLARE_MPI_SYNONYM_DDT; - Reviewed by George and Jeff This commit was SVN r15133.
2007-06-19 05:03:11 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
FUNC_FUNC(min, fortran_real4, ompi_fortran_real4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
FUNC_FUNC(min, fortran_real8, ompi_fortran_real8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
FUNC_FUNC(min, fortran_real16, ompi_fortran_real16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Sum
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
OP_FUNC(sum, int8_t, int8_t, +=)
OP_FUNC(sum, uint8_t, uint8_t, +=)
OP_FUNC(sum, int16_t, int16_t, +=)
OP_FUNC(sum, uint16_t, uint16_t, +=)
OP_FUNC(sum, int32_t, int32_t, +=)
OP_FUNC(sum, uint32_t, uint32_t, +=)
OP_FUNC(sum, int64_t, int64_t, +=)
OP_FUNC(sum, uint64_t, uint64_t, +=)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
OP_FUNC(sum, fortran_integer, ompi_fortran_integer_t, +=)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
OP_FUNC(sum, fortran_integer1, ompi_fortran_integer1_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
OP_FUNC(sum, fortran_integer2, ompi_fortran_integer2_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
OP_FUNC(sum, fortran_integer4, ompi_fortran_integer4_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
OP_FUNC(sum, fortran_integer8, ompi_fortran_integer8_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
OP_FUNC(sum, fortran_integer16, ompi_fortran_integer16_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Floating point */
OP_FUNC(sum, float, float, +=)
OP_FUNC(sum, double, double, +=)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
OP_FUNC(sum, long_double, long double, +=)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
OP_FUNC(sum, fortran_real, ompi_fortran_real_t, +=)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
OP_FUNC(sum, fortran_double_precision, ompi_fortran_double_precision_t, +=)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
OP_FUNC(sum, fortran_real2, ompi_fortran_real2_t, +=)
- Support for opt. MPI_REAL2 (who has that?) to make checks for MPI-implementations fail in the right way ,-] - check in configure.ac - BINARY INCOMPATIBLE change to mpif-common.h (if implemented the *right* way) Actually OMPI_F90_CHECK takes two arguments, not three. - Only have corresponding C-Type, if the opt. Fortran type is really supported, Otherwise pass ompi_mpi_unavailable to DECLARE_MPI_SYNONYM_DDT; - Reviewed by George and Jeff This commit was SVN r15133.
2007-06-19 05:03:11 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
OP_FUNC(sum, fortran_real4, ompi_fortran_real4_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
OP_FUNC(sum, fortran_real8, ompi_fortran_real8_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
OP_FUNC(sum, fortran_real16, ompi_fortran_real16_t, +=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Complex */
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#if HAVE_FLOAT__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC(sum, c_float_complex, float _Complex, +=)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC(sum, c_double_complex, double _Complex, +=)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_LONG_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC(sum, c_long_double_complex, long double _Complex, +=)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Product
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
OP_FUNC(prod, int8_t, int8_t, *=)
OP_FUNC(prod, uint8_t, uint8_t, *=)
OP_FUNC(prod, int16_t, int16_t, *=)
OP_FUNC(prod, uint16_t, uint16_t, *=)
OP_FUNC(prod, int32_t, int32_t, *=)
OP_FUNC(prod, uint32_t, uint32_t, *=)
OP_FUNC(prod, int64_t, int64_t, *=)
OP_FUNC(prod, uint64_t, uint64_t, *=)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
OP_FUNC(prod, fortran_integer, ompi_fortran_integer_t, *=)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
OP_FUNC(prod, fortran_integer1, ompi_fortran_integer1_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
OP_FUNC(prod, fortran_integer2, ompi_fortran_integer2_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
OP_FUNC(prod, fortran_integer4, ompi_fortran_integer4_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
OP_FUNC(prod, fortran_integer8, ompi_fortran_integer8_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
OP_FUNC(prod, fortran_integer16, ompi_fortran_integer16_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Floating point */
OP_FUNC(prod, float, float, *=)
OP_FUNC(prod, double, double, *=)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
OP_FUNC(prod, long_double, long double, *=)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
OP_FUNC(prod, fortran_real, ompi_fortran_real_t, *=)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
OP_FUNC(prod, fortran_double_precision, ompi_fortran_double_precision_t, *=)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
OP_FUNC(prod, fortran_real2, ompi_fortran_real2_t, *=)
- Support for opt. MPI_REAL2 (who has that?) to make checks for MPI-implementations fail in the right way ,-] - check in configure.ac - BINARY INCOMPATIBLE change to mpif-common.h (if implemented the *right* way) Actually OMPI_F90_CHECK takes two arguments, not three. - Only have corresponding C-Type, if the opt. Fortran type is really supported, Otherwise pass ompi_mpi_unavailable to DECLARE_MPI_SYNONYM_DDT; - Reviewed by George and Jeff This commit was SVN r15133.
2007-06-19 05:03:11 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
OP_FUNC(prod, fortran_real4, ompi_fortran_real4_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
OP_FUNC(prod, fortran_real8, ompi_fortran_real8_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
OP_FUNC(prod, fortran_real16, ompi_fortran_real16_t, *=)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Complex */
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#if HAVE_FLOAT__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC(prod, c_float_complex, float _Complex, *=)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC(prod, c_double_complex, double _Complex, *=)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_LONG_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC(prod, c_long_double_complex, long double _Complex, *=)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Logical AND
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) && (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(land, int8_t, int8_t)
FUNC_FUNC(land, uint8_t, uint8_t)
FUNC_FUNC(land, int16_t, int16_t)
FUNC_FUNC(land, uint16_t, uint16_t)
FUNC_FUNC(land, int32_t, int32_t)
FUNC_FUNC(land, uint32_t, uint32_t)
FUNC_FUNC(land, int64_t, int64_t)
FUNC_FUNC(land, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Logical */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
FUNC_FUNC(land, fortran_logical, ompi_fortran_logical_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
Shame on me for not looking at the expanded collective datatype tables for the C++ bindings in MPI-2 p276-278 to see that MPI_BOOL should work with MPI_LAND, MPI_LOR, and MPI_LXOR. Thanks to Andy Selle for pointing this out. This commit was SVN r9200.
2006-03-04 18:35:33 +00:00
/* C++ bool */
FUNC_FUNC(land, bool, bool)
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Logical OR
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) || (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(lor, int8_t, int8_t)
FUNC_FUNC(lor, uint8_t, uint8_t)
FUNC_FUNC(lor, int16_t, int16_t)
FUNC_FUNC(lor, uint16_t, uint16_t)
FUNC_FUNC(lor, int32_t, int32_t)
FUNC_FUNC(lor, uint32_t, uint32_t)
FUNC_FUNC(lor, int64_t, int64_t)
FUNC_FUNC(lor, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Logical */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
FUNC_FUNC(lor, fortran_logical, ompi_fortran_logical_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
Shame on me for not looking at the expanded collective datatype tables for the C++ bindings in MPI-2 p276-278 to see that MPI_BOOL should work with MPI_LAND, MPI_LOR, and MPI_LXOR. Thanks to Andy Selle for pointing this out. This commit was SVN r9200.
2006-03-04 18:35:33 +00:00
/* C++ bool */
FUNC_FUNC(lor, bool, bool)
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Logical XOR
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
LXOR is a logical xor not a bitwise one, so using the ^ operation is not correct. Advance the buffers for the *LOC operations. This commit was SVN r1721.
2004-07-14 19:16:13 +00:00
#define current_func(a, b) ((a ? 1 : 0) ^ (b ? 1: 0))
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(lxor, int8_t, int8_t)
FUNC_FUNC(lxor, uint8_t, uint8_t)
FUNC_FUNC(lxor, int16_t, int16_t)
FUNC_FUNC(lxor, uint16_t, uint16_t)
FUNC_FUNC(lxor, int32_t, int32_t)
FUNC_FUNC(lxor, uint32_t, uint32_t)
FUNC_FUNC(lxor, int64_t, int64_t)
FUNC_FUNC(lxor, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Logical */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
FUNC_FUNC(lxor, fortran_logical, ompi_fortran_logical_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
Shame on me for not looking at the expanded collective datatype tables for the C++ bindings in MPI-2 p276-278 to see that MPI_BOOL should work with MPI_LAND, MPI_LOR, and MPI_LXOR. Thanks to Andy Selle for pointing this out. This commit was SVN r9200.
2006-03-04 18:35:33 +00:00
/* C++ bool */
FUNC_FUNC(lxor, bool, bool)
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Bitwise AND
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) & (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(band, int8_t, int8_t)
FUNC_FUNC(band, uint8_t, uint8_t)
FUNC_FUNC(band, int16_t, int16_t)
FUNC_FUNC(band, uint16_t, uint16_t)
FUNC_FUNC(band, int32_t, int32_t)
FUNC_FUNC(band, uint32_t, uint32_t)
FUNC_FUNC(band, int64_t, int64_t)
FUNC_FUNC(band, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC(band, fortran_integer, ompi_fortran_integer_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC(band, fortran_integer1, ompi_fortran_integer1_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC(band, fortran_integer2, ompi_fortran_integer2_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC(band, fortran_integer4, ompi_fortran_integer4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC(band, fortran_integer8, ompi_fortran_integer8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC(band, fortran_integer16, ompi_fortran_integer16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Byte */
FUNC_FUNC(band, byte, char)
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Bitwise OR
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) | (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(bor, int8_t, int8_t)
FUNC_FUNC(bor, uint8_t, uint8_t)
FUNC_FUNC(bor, int16_t, int16_t)
FUNC_FUNC(bor, uint16_t, uint16_t)
FUNC_FUNC(bor, int32_t, int32_t)
FUNC_FUNC(bor, uint32_t, uint32_t)
FUNC_FUNC(bor, int64_t, int64_t)
FUNC_FUNC(bor, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC(bor, fortran_integer, ompi_fortran_integer_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC(bor, fortran_integer1, ompi_fortran_integer1_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC(bor, fortran_integer2, ompi_fortran_integer2_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC(bor, fortran_integer4, ompi_fortran_integer4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC(bor, fortran_integer8, ompi_fortran_integer8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC(bor, fortran_integer16, ompi_fortran_integer16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Byte */
FUNC_FUNC(bor, byte, char)
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/*************************************************************************
* Bitwise XOR
*************************************************************************/
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
#undef current_func
#define current_func(a, b) ((a) ^ (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC(bxor, int8_t, int8_t)
FUNC_FUNC(bxor, uint8_t, uint8_t)
FUNC_FUNC(bxor, int16_t, int16_t)
FUNC_FUNC(bxor, uint16_t, uint16_t)
FUNC_FUNC(bxor, int32_t, int32_t)
FUNC_FUNC(bxor, uint32_t, uint32_t)
FUNC_FUNC(bxor, int64_t, int64_t)
FUNC_FUNC(bxor, uint64_t, uint64_t)
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC(bxor, fortran_integer, ompi_fortran_integer_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC(bxor, fortran_integer1, ompi_fortran_integer1_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC(bxor, fortran_integer2, ompi_fortran_integer2_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC(bxor, fortran_integer4, ompi_fortran_integer4_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC(bxor, fortran_integer8, ompi_fortran_integer8_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC(bxor, fortran_integer16, ompi_fortran_integer16_t)
A bunch of changes to support MPI_INTEGER*x, MPI_REAL*x, MPI_COMPLEX*x, and some optional C datatypes in MPI reduction operations. These types are not technically supported by the letter of the MPI standard, but are implied by the spirit of it (and there are definitely users that use them in real applications) - Add checks in configure for back-end C types for MPI_INTEGER*x and MPI_REAL*x - Create C data structs for MPI_COMPLEX*x - Fixed typo for MPI_INTEGER8 in mpi.h - Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion (between C "*_INT" names and Fortran "*_INT" names). This caused some trivial updates in ddt, ompi_info, and the MPI layer to match. - Update ompi_info to show whether we have each MPI_INTEGER*x, MPI_REAL*x, and MPI_COMPLEX*x - Extended reduction operations for optional datatypes: - "C integer" now includes long long int, long long, and unsigned long long - "Fortran integer" now includes MPI_INTEGER*x - "Floating point" now includes MPI_REAL*x - "Complex" now includes MPI_COMPLEX*x This commit was SVN r5511.
2005-04-27 10:23:06 +00:00
#endif
Lots of changes in this commit, mostly having to do with the first real commit of the collectives. MPI_SCAN and MPI_EXSCAN are still not implemented, but lots of other things are in the critical path and holding up other people, so it's ok to commit without them: - better checks for sizes in configure, and add defaults for fortran sizes if we don't have a fortran compiler - fix some logic that was accidentally broken for size checks for the file type offset_t - add some C equivalent types for fortran's complex and double complex (for use in internal reduction/op functions) - additionals and slight reorganization of ompi_mpi_init() ompi_mpi_finalize() - fully implement all top-level MPI collective calls, including all param checking for both intra- and inter-communicators (woof) - change the communicator_t type for stuff that we need in coll, and update all references throughout the code base to match - all kinds of updates to the coll framework base - next cut of the basic coll module -- has all intracommunicator collectives implemented except scan and exscan (see note above). All intercommunicator functions return ERR_NOT_IMPLEMENTED. - MPI_Op is a fixed implementation -- not component-ized yet. So there are generic C loops for all implementations. This commit was SVN r1491.
2004-06-29 00:02:25 +00:00
/* Byte */
FUNC_FUNC(bxor, byte, char)
First cut of op handling -- now link-compatible. Still have work to be done: - need to define internal op_create function (that MPI_OP_CREATE will call) - need to fill in all the handler functions that are the back-ends to the intrinsic MPI operations (e.g., MPI_SUM, MPI_MAX, etc.) This commit was SVN r1061.
2004-04-20 22:37:46 +00:00
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
/*************************************************************************
* Min and max location "pair" datatypes
*************************************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
LOC_STRUCT(2real, ompi_fortran_real_t, ompi_fortran_real_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
LOC_STRUCT(2double_precision, ompi_fortran_double_precision_t, ompi_fortran_double_precision_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
LOC_STRUCT(2integer, ompi_fortran_integer_t, ompi_fortran_integer_t)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_STRUCT(float_int, float, int)
LOC_STRUCT(double_int, double, int)
LOC_STRUCT(long_int, long, int)
LOC_STRUCT(2int, int, int)
Fix some minor errors in the predefined MPI_Op's This commit was SVN r2880.
2004-09-29 21:08:29 +00:00
LOC_STRUCT(short_int, short, int)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_STRUCT(long_double_int, long double, int)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#endif
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
/*************************************************************************
* Max location
*************************************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(maxloc, 2real, >)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(maxloc, 2double_precision, >)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(maxloc, 2integer, >)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(maxloc, float_int, >)
LOC_FUNC(maxloc, double_int, >)
LOC_FUNC(maxloc, long_int, >)
LOC_FUNC(maxloc, 2int, >)
LOC_FUNC(maxloc, short_int, >)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(maxloc, long_double_int, >)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#endif
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
/*************************************************************************
* Min location
*************************************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(minloc, 2real, <)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(minloc, 2double_precision, <)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(minloc, 2integer, <)
Bunches of fixes for Fortran support: - Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op reduction operations. - Update ddt to fully support these types as well, to include using the results of sizes and alignments determined by configure - Discover the goodness of m4 and consolidate a LOT of configure code (i.e., remove a lot of essentially duplicated code and m4-subroutine-ize it). The big kicker was figuring out how to parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4 properly. - If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't error. Just set the right flags so that we don't support them in the MPI layer. This commit was SVN r5788.
2005-05-19 23:56:02 +00:00
#endif
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(minloc, float_int, <)
LOC_FUNC(minloc, double_int, <)
LOC_FUNC(minloc, long_int, <)
LOC_FUNC(minloc, 2int, <)
LOC_FUNC(minloc, short_int, <)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#if HAVE_LONG_DOUBLE
- Code review by George; fix some minor errors - Add MINLOC and MAXLOC - Add REPLACE This commit was SVN r1672.
2004-07-13 15:20:46 +00:00
LOC_FUNC(minloc, long_double_int, <)
- Should make declare only, when we do have long double. This commit was SVN r15130.
2007-06-18 22:59:21 +00:00
#endif
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/*
* This is a three buffer (2 input and 1 output) version of the reduction
* routines, needed for some optimizations.
*/
#define OP_FUNC_3BUF(name, type_name, type, op) \
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
static void ompi_op_base_3buff_##name##_##type_name(void * restrict in1, \
void * restrict in2, void * restrict out, int *count, \
struct ompi_datatype_t **dtype, \
struct ompi_op_base_module_1_0_0_t *module) \
{ \
int i; \
type *a1 = (type *) in1; \
type *a2 = (type *) in2; \
type *b = (type *) out; \
for (i = 0; i < *count; ++i) { \
*(b++) = *(a1++) op *(a2++); \
} \
}
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/*
* Since all the functions in this file are essentially identical, we
* use a macro to substitute in names and types. The core operation
* in all functions that use this macro is the same.
*
* This macro is for (out = op(in1, in2))
*/
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FUNC_FUNC_3BUF(name, type_name, type) \
static void ompi_op_base_3buff_##name##_##type_name(void * restrict in1, \
void * restrict in2, void * restrict out, int *count, \
struct ompi_datatype_t **dtype, \
struct ompi_op_base_module_1_0_0_t *module) \
{ \
int i; \
type *a1 = (type *) in1; \
type *a2 = (type *) in2; \
type *b = (type *) out; \
for (i = 0; i < *count; ++i) { \
*(b) = current_func(*(a1), *(a2)); \
++b; \
++a1; \
++a2; \
} \
}
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/*
* Since all the functions in this file are essentially identical, we
* use a macro to substitute in names and types. The core operation
* in all functions that use this macro is the same.
*
* This macro is for minloc and maxloc
*/
/*
#define LOC_STRUCT(type_name, type1, type2) \
typedef struct { \
Cosmetic changes: * Update to 4 space tabs where relevant (and some irrelevant white space changes) * Move a few constants to the left of !=/== * Add a few {}'s are one line blocks * Use BEGIN/END_C_DECLS * Change /**< to /** in a few places This commit was SVN r20177.
2008-12-31 14:50:54 +00:00
type1 v; \
type2 k; \
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
} ompi_op_predefined_##type_name##_t;
*/
#define LOC_FUNC_3BUF(name, type_name, op) \
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
static void ompi_op_base_3buff_##name##_##type_name(void * restrict in1, \
void * restrict in2, void * restrict out, int *count, \
struct ompi_datatype_t **dtype, \
struct ompi_op_base_module_1_0_0_t *module) \
{ \
int i; \
Cosmetic changes: * Update to 4 space tabs where relevant (and some irrelevant white space changes) * Move a few constants to the left of !=/== * Add a few {}'s are one line blocks * Use BEGIN/END_C_DECLS * Change /**< to /** in a few places This commit was SVN r20177.
2008-12-31 14:50:54 +00:00
ompi_op_predefined_##type_name##_t *a1 = (ompi_op_predefined_##type_name##_t*) in1; \
ompi_op_predefined_##type_name##_t *a2 = (ompi_op_predefined_##type_name##_t*) in2; \
ompi_op_predefined_##type_name##_t *b = (ompi_op_predefined_##type_name##_t*) out; \
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
for (i = 0; i < *count; ++i, ++a1, ++a2, ++b ) { \
if (a1->v op a2->v) { \
b->v = a1->v; \
b->k = a1->k; \
} else if (a1->v == a2->v) { \
b->v = a1->v; \
b->k = (a2->k < a1->k ? a2->k : a1->k); \
} else { \
b->v = a2->v; \
b->k = a2->k; \
} \
} \
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
}
/*************************************************************************
* Max
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) > (b) ? (a) : (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(max, int8_t, int8_t)
FUNC_FUNC_3BUF(max, uint8_t, uint8_t)
FUNC_FUNC_3BUF(max, int16_t, int16_t)
FUNC_FUNC_3BUF(max, uint16_t, uint16_t)
FUNC_FUNC_3BUF(max, int32_t, int32_t)
FUNC_FUNC_3BUF(max, uint32_t, uint32_t)
FUNC_FUNC_3BUF(max, int64_t, int64_t)
FUNC_FUNC_3BUF(max, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC_3BUF(max, fortran_integer, ompi_fortran_integer_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC_3BUF(max, fortran_integer1, ompi_fortran_integer1_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC_3BUF(max, fortran_integer2, ompi_fortran_integer2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC_3BUF(max, fortran_integer4, ompi_fortran_integer4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC_3BUF(max, fortran_integer8, ompi_fortran_integer8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC_3BUF(max, fortran_integer16, ompi_fortran_integer16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Floating point */
FUNC_FUNC_3BUF(max, float, float)
FUNC_FUNC_3BUF(max, double, double)
#if HAVE_LONG_DOUBLE
FUNC_FUNC_3BUF(max, long_double, long double)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
FUNC_FUNC_3BUF(max, fortran_real, ompi_fortran_real_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
FUNC_FUNC_3BUF(max, fortran_double_precision, ompi_fortran_double_precision_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
FUNC_FUNC_3BUF(max, fortran_real2, ompi_fortran_real2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
FUNC_FUNC_3BUF(max, fortran_real4, ompi_fortran_real4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
FUNC_FUNC_3BUF(max, fortran_real8, ompi_fortran_real8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
FUNC_FUNC_3BUF(max, fortran_real16, ompi_fortran_real16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/*************************************************************************
* Min
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) < (b) ? (a) : (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(min, int8_t, int8_t)
FUNC_FUNC_3BUF(min, uint8_t, uint8_t)
FUNC_FUNC_3BUF(min, int16_t, int16_t)
FUNC_FUNC_3BUF(min, uint16_t, uint16_t)
FUNC_FUNC_3BUF(min, int32_t, int32_t)
FUNC_FUNC_3BUF(min, uint32_t, uint32_t)
FUNC_FUNC_3BUF(min, int64_t, int64_t)
FUNC_FUNC_3BUF(min, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC_3BUF(min, fortran_integer, ompi_fortran_integer_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC_3BUF(min, fortran_integer1, ompi_fortran_integer1_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC_3BUF(min, fortran_integer2, ompi_fortran_integer2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC_3BUF(min, fortran_integer4, ompi_fortran_integer4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC_3BUF(min, fortran_integer8, ompi_fortran_integer8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC_3BUF(min, fortran_integer16, ompi_fortran_integer16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Floating point */
FUNC_FUNC_3BUF(min, float, float)
FUNC_FUNC_3BUF(min, double, double)
#if HAVE_LONG_DOUBLE
FUNC_FUNC_3BUF(min, long_double, long double)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
FUNC_FUNC_3BUF(min, fortran_real, ompi_fortran_real_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
FUNC_FUNC_3BUF(min, fortran_double_precision, ompi_fortran_double_precision_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
FUNC_FUNC_3BUF(min, fortran_real2, ompi_fortran_real2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
FUNC_FUNC_3BUF(min, fortran_real4, ompi_fortran_real4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
FUNC_FUNC_3BUF(min, fortran_real8, ompi_fortran_real8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
FUNC_FUNC_3BUF(min, fortran_real16, ompi_fortran_real16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/*************************************************************************
* Sum
*************************************************************************/
/* C integer */
Ahem ... Correctly implement most of the 3 arguments operator in Open MPI. Creepy that it was not discovered earlier. cmr=v1.8.2:reviewer=ompi-rm1.8 This commit was SVN r31473.
2014-04-21 23:31:23 +00:00
OP_FUNC_3BUF(sum, int8_t, int8_t, +)
OP_FUNC_3BUF(sum, uint8_t, uint8_t, +)
OP_FUNC_3BUF(sum, int16_t, int16_t, +)
OP_FUNC_3BUF(sum, uint16_t, uint16_t, +)
OP_FUNC_3BUF(sum, int32_t, int32_t, +)
OP_FUNC_3BUF(sum, uint32_t, uint32_t, +)
OP_FUNC_3BUF(sum, int64_t, int64_t, +)
OP_FUNC_3BUF(sum, uint64_t, uint64_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
OP_FUNC_3BUF(sum, fortran_integer, ompi_fortran_integer_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
OP_FUNC_3BUF(sum, fortran_integer1, ompi_fortran_integer1_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
OP_FUNC_3BUF(sum, fortran_integer2, ompi_fortran_integer2_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
OP_FUNC_3BUF(sum, fortran_integer4, ompi_fortran_integer4_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
OP_FUNC_3BUF(sum, fortran_integer8, ompi_fortran_integer8_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
OP_FUNC_3BUF(sum, fortran_integer16, ompi_fortran_integer16_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Floating point */
OP_FUNC_3BUF(sum, float, float, +)
OP_FUNC_3BUF(sum, double, double, +)
#if HAVE_LONG_DOUBLE
OP_FUNC_3BUF(sum, long_double, long double, +)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
OP_FUNC_3BUF(sum, fortran_real, ompi_fortran_real_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
OP_FUNC_3BUF(sum, fortran_double_precision, ompi_fortran_double_precision_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
OP_FUNC_3BUF(sum, fortran_real2, ompi_fortran_real2_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
OP_FUNC_3BUF(sum, fortran_real4, ompi_fortran_real4_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
OP_FUNC_3BUF(sum, fortran_real8, ompi_fortran_real8_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
OP_FUNC_3BUF(sum, fortran_real16, ompi_fortran_real16_t, +)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Complex */
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#if HAVE_FLOAT__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC_3BUF(sum, c_float_complex, float _Complex, +)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC_3BUF(sum, c_double_complex, double _Complex, +)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_LONG_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC_3BUF(sum, c_long_double_complex, long double _Complex, +)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/*************************************************************************
* Product
*************************************************************************/
/* C integer */
Ahem ... Correctly implement most of the 3 arguments operator in Open MPI. Creepy that it was not discovered earlier. cmr=v1.8.2:reviewer=ompi-rm1.8 This commit was SVN r31473.
2014-04-21 23:31:23 +00:00
OP_FUNC_3BUF(prod, int8_t, int8_t, *)
OP_FUNC_3BUF(prod, uint8_t, uint8_t, *)
OP_FUNC_3BUF(prod, int16_t, int16_t, *)
OP_FUNC_3BUF(prod, uint16_t, uint16_t, *)
OP_FUNC_3BUF(prod, int32_t, int32_t, *)
OP_FUNC_3BUF(prod, uint32_t, uint32_t, *)
OP_FUNC_3BUF(prod, int64_t, int64_t, *)
OP_FUNC_3BUF(prod, uint64_t, uint64_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
OP_FUNC_3BUF(prod, fortran_integer, ompi_fortran_integer_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
OP_FUNC_3BUF(prod, fortran_integer1, ompi_fortran_integer1_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
OP_FUNC_3BUF(prod, fortran_integer2, ompi_fortran_integer2_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
OP_FUNC_3BUF(prod, fortran_integer4, ompi_fortran_integer4_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
OP_FUNC_3BUF(prod, fortran_integer8, ompi_fortran_integer8_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
OP_FUNC_3BUF(prod, fortran_integer16, ompi_fortran_integer16_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Floating point */
OP_FUNC_3BUF(prod, float, float, *)
OP_FUNC_3BUF(prod, double, double, *)
#if HAVE_LONG_DOUBLE
OP_FUNC_3BUF(prod, long_double, long double, *)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
OP_FUNC_3BUF(prod, fortran_real, ompi_fortran_real_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
OP_FUNC_3BUF(prod, fortran_double_precision, ompi_fortran_double_precision_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
OP_FUNC_3BUF(prod, fortran_real2, ompi_fortran_real2_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
OP_FUNC_3BUF(prod, fortran_real4, ompi_fortran_real4_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
OP_FUNC_3BUF(prod, fortran_real8, ompi_fortran_real8_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
Remove warnings identified by clang 3.4 * Remove unused static functions * Remove unused static variables cmr=v1.8:reviewer=hjelmn This commit was SVN r31023.
2014-03-12 13:17:54 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
OP_FUNC_3BUF(prod, fortran_real16, ompi_fortran_real16_t, *)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Complex */
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#if HAVE_FLOAT__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC_3BUF(prod, c_float_complex, float _Complex, *)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC_3BUF(prod, c_double_complex, double _Complex, *)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
#if HAVE_LONG_DOUBLE__COMPLEX
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
OP_FUNC_3BUF(prod, c_long_double_complex, long double _Complex, *)
Fix support for complex datatypes when fortran is not available but _Complex is This commit was SVN r28951.
2013-07-25 19:08:21 +00:00
#endif
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/*************************************************************************
* Logical AND
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) && (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(land, int8_t, int8_t)
FUNC_FUNC_3BUF(land, uint8_t, uint8_t)
FUNC_FUNC_3BUF(land, int16_t, int16_t)
FUNC_FUNC_3BUF(land, uint16_t, uint16_t)
FUNC_FUNC_3BUF(land, int32_t, int32_t)
FUNC_FUNC_3BUF(land, uint32_t, uint32_t)
FUNC_FUNC_3BUF(land, int64_t, int64_t)
FUNC_FUNC_3BUF(land, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Logical */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
FUNC_FUNC_3BUF(land, fortran_logical, ompi_fortran_logical_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* C++ bool */
FUNC_FUNC_3BUF(land, bool, bool)
/*************************************************************************
* Logical OR
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) || (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(lor, int8_t, int8_t)
FUNC_FUNC_3BUF(lor, uint8_t, uint8_t)
FUNC_FUNC_3BUF(lor, int16_t, int16_t)
FUNC_FUNC_3BUF(lor, uint16_t, uint16_t)
FUNC_FUNC_3BUF(lor, int32_t, int32_t)
FUNC_FUNC_3BUF(lor, uint32_t, uint32_t)
FUNC_FUNC_3BUF(lor, int64_t, int64_t)
FUNC_FUNC_3BUF(lor, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Logical */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
FUNC_FUNC_3BUF(lor, fortran_logical, ompi_fortran_logical_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* C++ bool */
FUNC_FUNC_3BUF(lor, bool, bool)
/*************************************************************************
* Logical XOR
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a ? 1 : 0) ^ (b ? 1: 0))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(lxor, int8_t, int8_t)
FUNC_FUNC_3BUF(lxor, uint8_t, uint8_t)
FUNC_FUNC_3BUF(lxor, int16_t, int16_t)
FUNC_FUNC_3BUF(lxor, uint16_t, uint16_t)
FUNC_FUNC_3BUF(lxor, int32_t, int32_t)
FUNC_FUNC_3BUF(lxor, uint32_t, uint32_t)
FUNC_FUNC_3BUF(lxor, int64_t, int64_t)
FUNC_FUNC_3BUF(lxor, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Logical */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
FUNC_FUNC_3BUF(lxor, fortran_logical, ompi_fortran_logical_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* C++ bool */
FUNC_FUNC_3BUF(lxor, bool, bool)
/*************************************************************************
* Bitwise AND
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) & (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(band, int8_t, int8_t)
FUNC_FUNC_3BUF(band, uint8_t, uint8_t)
FUNC_FUNC_3BUF(band, int16_t, int16_t)
FUNC_FUNC_3BUF(band, uint16_t, uint16_t)
FUNC_FUNC_3BUF(band, int32_t, int32_t)
FUNC_FUNC_3BUF(band, uint32_t, uint32_t)
FUNC_FUNC_3BUF(band, int64_t, int64_t)
FUNC_FUNC_3BUF(band, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC_3BUF(band, fortran_integer, ompi_fortran_integer_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC_3BUF(band, fortran_integer1, ompi_fortran_integer1_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC_3BUF(band, fortran_integer2, ompi_fortran_integer2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC_3BUF(band, fortran_integer4, ompi_fortran_integer4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC_3BUF(band, fortran_integer8, ompi_fortran_integer8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC_3BUF(band, fortran_integer16, ompi_fortran_integer16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Byte */
FUNC_FUNC_3BUF(band, byte, char)
/*************************************************************************
* Bitwise OR
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) | (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(bor, int8_t, int8_t)
FUNC_FUNC_3BUF(bor, uint8_t, uint8_t)
FUNC_FUNC_3BUF(bor, int16_t, int16_t)
FUNC_FUNC_3BUF(bor, uint16_t, uint16_t)
FUNC_FUNC_3BUF(bor, int32_t, int32_t)
FUNC_FUNC_3BUF(bor, uint32_t, uint32_t)
FUNC_FUNC_3BUF(bor, int64_t, int64_t)
FUNC_FUNC_3BUF(bor, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC_3BUF(bor, fortran_integer, ompi_fortran_integer_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC_3BUF(bor, fortran_integer1, ompi_fortran_integer1_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC_3BUF(bor, fortran_integer2, ompi_fortran_integer2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC_3BUF(bor, fortran_integer4, ompi_fortran_integer4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC_3BUF(bor, fortran_integer8, ompi_fortran_integer8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC_3BUF(bor, fortran_integer16, ompi_fortran_integer16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Byte */
FUNC_FUNC_3BUF(bor, byte, char)
/*************************************************************************
* Bitwise XOR
*************************************************************************/
#undef current_func
#define current_func(a, b) ((a) ^ (b))
/* C integer */
Reshape the datatype engine. The basic types are built down in OPAL. MPI types are either direct link to these basic predefined types, or a combination of them. Anyway, the first items in the datatype list belong to OPAL, the second round are MPI datatypes created by composing basic OPAL datatypes, and the last batch are mapped datatype (direct correspondance between an OMPI datatype and an OPAL one such as int -> int32_t). Modify the op to fit this new scheme. This commit was SVN r24247.
2011-01-13 06:08:54 +00:00
FUNC_FUNC_3BUF(bxor, int8_t, int8_t)
FUNC_FUNC_3BUF(bxor, uint8_t, uint8_t)
FUNC_FUNC_3BUF(bxor, int16_t, int16_t)
FUNC_FUNC_3BUF(bxor, uint16_t, uint16_t)
FUNC_FUNC_3BUF(bxor, int32_t, int32_t)
FUNC_FUNC_3BUF(bxor, uint32_t, uint32_t)
FUNC_FUNC_3BUF(bxor, int64_t, int64_t)
FUNC_FUNC_3BUF(bxor, uint64_t, uint64_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
/* Fortran integer */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
FUNC_FUNC_3BUF(bxor, fortran_integer, ompi_fortran_integer_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
FUNC_FUNC_3BUF(bxor, fortran_integer1, ompi_fortran_integer1_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
FUNC_FUNC_3BUF(bxor, fortran_integer2, ompi_fortran_integer2_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
FUNC_FUNC_3BUF(bxor, fortran_integer4, ompi_fortran_integer4_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
FUNC_FUNC_3BUF(bxor, fortran_integer8, ompi_fortran_integer8_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
FUNC_FUNC_3BUF(bxor, fortran_integer16, ompi_fortran_integer16_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
/* Byte */
FUNC_FUNC_3BUF(bxor, byte, char)
/*************************************************************************
* Min and max location "pair" datatypes
*************************************************************************/
/*
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
LOC_STRUCT_3BUF(2real, ompi_fortran_real_t, ompi_fortran_real_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
LOC_STRUCT_3BUF(2double_precision, ompi_fortran_double_precision_t, ompi_fortran_double_precision_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
LOC_STRUCT_3BUF(2integer, ompi_fortran_integer_t, ompi_fortran_integer_t)
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
#endif
LOC_STRUCT_3BUF(float_int, float, int)
LOC_STRUCT_3BUF(double_int, double, int)
LOC_STRUCT_3BUF(long_int, long, int)
LOC_STRUCT_3BUF(2int, int, int)
LOC_STRUCT_3BUF(short_int, short, int)
#if HAVE_LONG_DOUBLE
LOC_STRUCT_3BUF(long_double_int, long double, int)
#endif
*/
/*************************************************************************
* Max location
*************************************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
LOC_FUNC_3BUF(maxloc, 2real, >)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
LOC_FUNC_3BUF(maxloc, 2double_precision, >)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
LOC_FUNC_3BUF(maxloc, 2integer, >)
#endif
LOC_FUNC_3BUF(maxloc, float_int, >)
LOC_FUNC_3BUF(maxloc, double_int, >)
LOC_FUNC_3BUF(maxloc, long_int, >)
LOC_FUNC_3BUF(maxloc, 2int, >)
LOC_FUNC_3BUF(maxloc, short_int, >)
#if HAVE_LONG_DOUBLE
LOC_FUNC_3BUF(maxloc, long_double_int, >)
#endif
/*************************************************************************
* Min location
*************************************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
LOC_FUNC_3BUF(minloc, 2real, <)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
LOC_FUNC_3BUF(minloc, 2double_precision, <)
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
add functions to handle two different input buffers and a separate output buffer. User defined data types have not way to make use of these. This commit was SVN r18012.
2008-03-28 23:45:44 +00:00
LOC_FUNC_3BUF(minloc, 2integer, <)
#endif
LOC_FUNC_3BUF(minloc, float_int, <)
LOC_FUNC_3BUF(minloc, double_int, <)
LOC_FUNC_3BUF(minloc, long_int, <)
LOC_FUNC_3BUF(minloc, 2int, <)
LOC_FUNC_3BUF(minloc, short_int, <)
#if HAVE_LONG_DOUBLE
LOC_FUNC_3BUF(minloc, long_double_int, <)
#endif
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/*
* Helpful defines, because there's soooo many names!
*
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
* **NOTE** These #define's used to be strictly ordered but the use of
* designated initializers removed this restrictions. When adding new
* operators ALWAYS use a designated initalizer!
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
*/
/** C integer ***********************************************************/
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define C_INTEGER(name, ftype) \
[OMPI_OP_BASE_TYPE_INT8_T] = ompi_op_base_##ftype##_##name##_int8_t, \
[OMPI_OP_BASE_TYPE_UINT8_T] = ompi_op_base_##ftype##_##name##_uint8_t, \
[OMPI_OP_BASE_TYPE_INT16_T] = ompi_op_base_##ftype##_##name##_int16_t, \
[OMPI_OP_BASE_TYPE_UINT16_T] = ompi_op_base_##ftype##_##name##_uint16_t, \
[OMPI_OP_BASE_TYPE_INT32_T] = ompi_op_base_##ftype##_##name##_int32_t, \
[OMPI_OP_BASE_TYPE_UINT32_T] = ompi_op_base_##ftype##_##name##_uint32_t, \
[OMPI_OP_BASE_TYPE_INT64_T] = ompi_op_base_##ftype##_##name##_int64_t, \
[OMPI_OP_BASE_TYPE_UINT64_T] = ompi_op_base_##ftype##_##name##_uint64_t
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/** All the Fortran integers ********************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER_PLAIN(name, ftype) ompi_op_base_##ftype##_##name##_fortran_integer
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER_PLAIN(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER1
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER1(name, ftype) ompi_op_base_##ftype##_##name##_fortran_integer1
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER1(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER2
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER2(name, ftype) ompi_op_base_##ftype##_##name##_fortran_integer2
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER2(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER4
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER4(name, ftype) ompi_op_base_##ftype##_##name##_fortran_integer4
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER4(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER8
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER8(name, ftype) ompi_op_base_##ftype##_##name##_fortran_integer8
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER8(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER16
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER16(name, ftype) ompi_op_base_##ftype##_##name##_fortran_integer16
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_INTEGER16(name, ftype) NULL
#endif
#define FORTRAN_INTEGER(name, ftype) \
[OMPI_OP_BASE_TYPE_INTEGER] = FORTRAN_INTEGER_PLAIN(name, ftype), \
[OMPI_OP_BASE_TYPE_INTEGER1] = FORTRAN_INTEGER1(name, ftype), \
[OMPI_OP_BASE_TYPE_INTEGER2] = FORTRAN_INTEGER2(name, ftype), \
[OMPI_OP_BASE_TYPE_INTEGER4] = FORTRAN_INTEGER4(name, ftype), \
[OMPI_OP_BASE_TYPE_INTEGER8] = FORTRAN_INTEGER8(name, ftype), \
[OMPI_OP_BASE_TYPE_INTEGER16] = FORTRAN_INTEGER16(name, ftype)
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/** All the Fortran reals ***********************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL_PLAIN(name, ftype) ompi_op_base_##ftype##_##name##_fortran_real
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL_PLAIN(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL2
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL2(name, ftype) ompi_op_base_##ftype##_##name##_fortran_real2
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL2(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL4
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL4(name, ftype) ompi_op_base_##ftype##_##name##_fortran_real4
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL4(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL8
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL8(name, ftype) ompi_op_base_##ftype##_##name##_fortran_real8
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL8(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
/* If:
- we have fortran REAL*16, *and*
- fortran REAL*16 matches the bit representation of the
corresponding C type
Only then do we put in function pointers for REAL*16 reductions.
Otherwise, just put in NULL. */
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL16 && OMPI_REAL16_MATCHES_C
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL16(name, ftype) ompi_op_base_##ftype##_##name##_fortran_real16
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL16(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_REAL(name, ftype) \
[OMPI_OP_BASE_TYPE_REAL] = FLOATING_POINT_FORTRAN_REAL_PLAIN(name, ftype), \
[OMPI_OP_BASE_TYPE_REAL2] = FLOATING_POINT_FORTRAN_REAL2(name, ftype), \
[OMPI_OP_BASE_TYPE_REAL4] = FLOATING_POINT_FORTRAN_REAL4(name, ftype), \
[OMPI_OP_BASE_TYPE_REAL8] = FLOATING_POINT_FORTRAN_REAL8(name, ftype), \
[OMPI_OP_BASE_TYPE_REAL16] = FLOATING_POINT_FORTRAN_REAL16(name, ftype)
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/** Fortran double precision ********************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT_FORTRAN_DOUBLE_PRECISION(name, ftype) \
ompi_op_base_##ftype##_##name##_fortran_double_precision
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Fix the case where we build without Fortran support. This commit was SVN r29194.
2013-09-17 20:45:46 +00:00
#define FLOATING_POINT_FORTRAN_DOUBLE_PRECISION(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
/** Floating point, including all the Fortran reals *********************/
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOATING_POINT(name, ftype) \
[OMPI_OP_BASE_TYPE_FLOAT] = ompi_op_base_##ftype##_##name##_float, \
[OMPI_OP_BASE_TYPE_DOUBLE] = ompi_op_base_##ftype##_##name##_double, \
FLOATING_POINT_FORTRAN_REAL(name, ftype), \
[OMPI_OP_BASE_TYPE_DOUBLE_PRECISION] = FLOATING_POINT_FORTRAN_DOUBLE_PRECISION(name, ftype), \
[OMPI_OP_BASE_TYPE_LONG_DOUBLE] = ompi_op_base_##ftype##_##name##_long_double
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/** Fortran logical *****************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_LOGICAL
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FORTRAN_LOGICAL(name, ftype) \
ompi_op_base_##ftype##_##name##_fortran_logical /* OMPI_OP_BASE_TYPE_LOGICAL */
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Fix the case where we build without Fortran support. This commit was SVN r29194.
2013-09-17 20:45:46 +00:00
#define FORTRAN_LOGICAL(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define LOGICAL(name, ftype) \
[OMPI_OP_BASE_TYPE_LOGICAL] = FORTRAN_LOGICAL(name, ftype), \
[OMPI_OP_BASE_TYPE_BOOL] = ompi_op_base_##ftype##_##name##_bool
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
/** Complex *****************************************************/
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define FLOAT_COMPLEX(name, ftype) ompi_op_base_##ftype##_##name##_c_float_complex
#define DOUBLE_COMPLEX(name, ftype) ompi_op_base_##ftype##_##name##_c_double_complex
#define LONG_DOUBLE_COMPLEX(name, ftype) ompi_op_base_##ftype##_##name##_c_long_double_complex
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define COMPLEX(name, ftype) \
[OMPI_OP_BASE_TYPE_C_FLOAT_COMPLEX] = FLOAT_COMPLEX(name, ftype), \
[OMPI_OP_BASE_TYPE_C_DOUBLE_COMPLEX] = DOUBLE_COMPLEX(name, ftype), \
[OMPI_OP_BASE_TYPE_C_LONG_DOUBLE_COMPLEX] = LONG_DOUBLE_COMPLEX(name, ftype)
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/** Byte ****************************************************************/
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define BYTE(name, ftype) \
[OMPI_OP_BASE_TYPE_BYTE] = ompi_op_base_##ftype##_##name##_byte
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/** Fortran complex *****************************************************/
/** Fortran "2" types ***************************************************/
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_REAL
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC_FORTRAN_2REAL(name, ftype) ompi_op_base_##ftype##_##name##_2real
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC_FORTRAN_2REAL(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_DOUBLE_PRECISION
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC_FORTRAN_2DOUBLE_PRECISION(name, ftype) ompi_op_base_##ftype##_##name##_2double_precision
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC_FORTRAN_2DOUBLE_PRECISION(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
- 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@95596d1814224971a3558c1150577730f3525185
2009-06-01 19:02:34 +00:00
#if OMPI_HAVE_FORTRAN_INTEGER
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC_FORTRAN_2INTEGER(name, ftype) ompi_op_base_##ftype##_##name##_2integer
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#else
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC_FORTRAN_2INTEGER(name, ftype) NULL
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
#endif
/** All "2" types *******************************************************/
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
#define TWOLOC(name, ftype) \
[OMPI_OP_BASE_TYPE_2REAL] = TWOLOC_FORTRAN_2REAL(name, ftype), \
[OMPI_OP_BASE_TYPE_2DOUBLE_PRECISION] = TWOLOC_FORTRAN_2DOUBLE_PRECISION(name, ftype), \
[OMPI_OP_BASE_TYPE_2INTEGER] = TWOLOC_FORTRAN_2INTEGER(name, ftype), \
[OMPI_OP_BASE_TYPE_FLOAT_INT] = ompi_op_base_##ftype##_##name##_float_int, \
[OMPI_OP_BASE_TYPE_DOUBLE_INT] = ompi_op_base_##ftype##_##name##_double_int, \
[OMPI_OP_BASE_TYPE_LONG_INT] = ompi_op_base_##ftype##_##name##_long_int, \
[OMPI_OP_BASE_TYPE_2INT] = ompi_op_base_##ftype##_##name##_2int, \
[OMPI_OP_BASE_TYPE_SHORT_INT] = ompi_op_base_##ftype##_##name##_short_int, \
[OMPI_OP_BASE_TYPE_LONG_DOUBLE_INT] = ompi_op_base_##ftype##_##name##_long_double_int
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/*
* MPI_OP_NULL
* All types
*/
#define FLAGS_NO_FLOAT \
(OMPI_OP_FLAGS_INTRINSIC | OMPI_OP_FLAGS_ASSOC | OMPI_OP_FLAGS_COMMUTE)
#define FLAGS \
(OMPI_OP_FLAGS_INTRINSIC | OMPI_OP_FLAGS_ASSOC | \
OMPI_OP_FLAGS_FLOAT_ASSOC | OMPI_OP_FLAGS_COMMUTE)
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
ompi_op_base_handler_fn_t ompi_op_base_functions[OMPI_OP_BASE_FORTRAN_OP_MAX][OMPI_OP_BASE_TYPE_MAX] =
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
{
/* Corresponds to MPI_OP_NULL */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_NULL] = {
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/* Leaving this empty puts in NULL for all entries */
NULL,
},
/* Corresponds to MPI_MAX */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MAX] = {
C_INTEGER(max, 2buff),
FORTRAN_INTEGER(max, 2buff),
FLOATING_POINT(max, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_MIN */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MIN] = {
C_INTEGER(min, 2buff),
FORTRAN_INTEGER(min, 2buff),
FLOATING_POINT(min, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_SUM */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_SUM] = {
C_INTEGER(sum, 2buff),
FORTRAN_INTEGER(sum, 2buff),
FLOATING_POINT(sum, 2buff),
COMPLEX(sum, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_PROD */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_PROD] = {
C_INTEGER(prod, 2buff),
FORTRAN_INTEGER(prod, 2buff),
FLOATING_POINT(prod, 2buff),
COMPLEX(prod, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_LAND */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_LAND] = {
C_INTEGER(land, 2buff),
LOGICAL(land, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_BAND */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_BAND] = {
C_INTEGER(band, 2buff),
FORTRAN_INTEGER(band, 2buff),
BYTE(band, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_LOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_LOR] = {
C_INTEGER(lor, 2buff),
LOGICAL(lor, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_BOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_BOR] = {
C_INTEGER(bor, 2buff),
FORTRAN_INTEGER(bor, 2buff),
BYTE(bor, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_LXOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_LXOR] = {
C_INTEGER(lxor, 2buff),
LOGICAL(lxor, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_BXOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_BXOR] = {
C_INTEGER(bxor, 2buff),
FORTRAN_INTEGER(bxor, 2buff),
BYTE(bxor, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_MAXLOC */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MAXLOC] = {
TWOLOC(maxloc, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_MINLOC */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MINLOC] = {
TWOLOC(minloc, 2buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_REPLACE */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_REPLACE] = {
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/* (MPI_ACCUMULATE is handled differently than the other
reductions, so just zero out its function
impementations here to ensure that users don't invoke
MPI_REPLACE with any reduction operations other than
ACCUMULATE) */
NULL,
},
};
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
ompi_op_base_3buff_handler_fn_t ompi_op_base_3buff_functions[OMPI_OP_BASE_FORTRAN_OP_MAX][OMPI_OP_BASE_TYPE_MAX] =
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
{
/* Corresponds to MPI_OP_NULL */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_NULL] = {
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/* Leaving this empty puts in NULL for all entries */
NULL,
},
/* Corresponds to MPI_MAX */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MAX] = {
C_INTEGER(max, 3buff),
FORTRAN_INTEGER(max, 3buff),
FLOATING_POINT(max, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_MIN */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MIN] = {
C_INTEGER(min, 3buff),
FORTRAN_INTEGER(min, 3buff),
FLOATING_POINT(min, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_SUM */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_SUM] = {
C_INTEGER(sum, 3buff),
FORTRAN_INTEGER(sum, 3buff),
FLOATING_POINT(sum, 3buff),
COMPLEX(sum, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_PROD */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_PROD] = {
C_INTEGER(prod, 3buff),
FORTRAN_INTEGER(prod, 3buff),
FLOATING_POINT(prod, 3buff),
COMPLEX(prod, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_LAND */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_LAND] ={
C_INTEGER(land, 3buff),
LOGICAL(land, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_BAND */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_BAND] = {
C_INTEGER(band, 3buff),
FORTRAN_INTEGER(band, 3buff),
BYTE(band, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_LOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_LOR] = {
C_INTEGER(lor, 3buff),
LOGICAL(lor, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_BOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_BOR] = {
C_INTEGER(bor, 3buff),
FORTRAN_INTEGER(bor, 3buff),
BYTE(bor, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_LXOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_LXOR] = {
C_INTEGER(lxor, 3buff),
LOGICAL(lxor, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_BXOR */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_BXOR] = {
C_INTEGER(bxor, 3buff),
FORTRAN_INTEGER(bxor, 3buff),
BYTE(bxor, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_MAXLOC */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MAXLOC] = {
TWOLOC(maxloc, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_MINLOC */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_MINLOC] = {
TWOLOC(minloc, 3buff),
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
},
/* Corresponds to MPI_REPLACE */
Cleanup complex datatypes and update datatypes and operator code to use C99. This commit changes the underlying opal complex datatypes to match the C99 types: float _Complex, double _Complex, and long double _Complex. The fortran and C++ types now are aliases to these basic types instead of structure types. The operators in ompi/mca/op/base now work on only the C99 types and the fortran types use these operators if the fortran type matches a C complex type (this should almost always be the case.) C99 is not is use in both the datatype and operator code and should make the code both cleaner and much less fragile. This commit was SVN r29193.
2013-09-17 17:49:42 +00:00
[OMPI_OP_BASE_FORTRAN_REPLACE] = {
Two major things in this commit: * New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
2009-01-14 23:44:31 +00:00
/* MPI_ACCUMULATE is handled differently than the other
reductions, so just zero out its function
impementations here to ensure that users don't invoke
MPI_REPLACE with any reduction operations other than
ACCUMULATE */
NULL,
},
};
Копировать постоянную ссылку