Jeff,
I get the following warnings from "make" using the Intel 2011.3.174
compilers on OpenMPI 1.4.3:
btl_openib_endpoint.c(319): warning #188: enumerated type mixed with
another type
btl_openib_async.c(411): warning #188: enumerated type mixed with
another type
btl_openib_async.c(454): warning #188: enumerated type mixed with
another type
btl_openib_async.c(472): warning #188: enumerated type mixed with
another type
btl_openib_async.c(510): warning #188: enumerated type mixed with
another type
connect/btl_openib_connect_oob.c(289): warning #188: enumerated type
mixed with another type
connect/btl_openib_connect_xoob.c(462): warning #188: enumerated
type mixed with another type
connect/btl_openib_connect_xoob.c(563): warning #188: enumerated
type mixed with another type
These are all warnings caused by mixing enums and ints as though they
were interchangeable. This concerns me, because, one can mistakenly
assume the only possible values of an enum data type are the range of
valid enum constants. That can make debugging such errors very
difficult. I do not know if you are aware of these.
I found the following:
1) ompi/mca/btl/openib/btl_openib/btl_openib_endpoint.c(319): warning
#188: enumerated type mixed with another type:
ep->rem_info.rem_transport_type = (remote_proc_info-
>pm_port_info).transport_type;
The left side is an enum mca_btl_openib_transport_type_t (from ompi/
mca/btl/openib/btl_openib.h):
/**
* Infiniband (IB) BTL component.
*/
typedef enum {
MCA_BTL_OPENIB_TRANSPORT_IB,
MCA_BTL_OPENIB_TRANSPORT_IWARP,
MCA_BTL_OPENIB_TRANSPORT_RDMAOE,
MCA_BTL_OPENIB_TRANSPORT_UNKNOWN,
MCA_BTL_OPENIB_TRANSPORT_SIZE
} mca_btl_openib_transport_type_t;
, while the right side is a uint8_t (also from ompi/mca/btl/openib/
btl_openib.h):
/**
* Common information for all ports that is sent in the modex message
*/
typedef struct mca_btl_openib_modex_message_t {
/** The subnet ID of this port */
uint64_t subnet_id;
/** LID of this port */
uint16_t lid;
/** APM LID for this port */
uint16_t apm_lid;
/** The MTU used by this port */
uint8_t mtu;
/** vendor id define device type and tuning */
uint32_t vendor_id;
/** vendor part id define device type and tuning */
uint32_t vendor_part_id;
/** Transport type of remote port */
uint8_t transport_type;
/** Dummy field used to calculate the real length */
uint8_t end;
} mca_btl_openib_modex_message_t;
I would think mca_btl_openib_modex_message_t.transport_type should be
a compatible enum as well. At least there should be some code
somewhere with asserts or validity checks in, say, a switch block when
DEBUG=1, and a cast otherwise.
2) ompi/mca/btl/openib/btl_openib/btl_openib_async.c(411): warning
#188: enumerated type mixed with another type, and
ompi/mca/btl/openib/btl_openib_async.c(454): warning #188: enumerated
type mixed with another type:
static ... ( ... enum ibv_qp_attr_mask *mask ... )
{
*mask = IBV_QP_ALT_PATH|IBV_QP_PATH_MIG_STATE;
ompi/mca/btl/openib/btl_openib_async.c(472): warning #188: enumerated
type mixed with another type, and
ompi/mca/btl/openib/btl_openib_async.c(510): warning #188: enumerated
type mixed with another type:
enum ibv_qp_attr_mask mask = 0;
These four warnings are all due to mixing the definition of bitfields
using a C enum type (from /usr/include/infiniband/verbs.h):
enum ibv_qp_attr_mask {
IBV_QP_STATE= 1 << 0,
IBV_QP_CUR_STATE= 1 << 1,
IBV_QP_EN_SQD_ASYNC_NOTIFY = 1 << 2,
IBV_QP_ACCESS_FLAGS = 1 << 3,
IBV_QP_PKEY_INDEX = 1 << 4,
IBV_QP_PORT = 1 << 5,
IBV_QP_QKEY = 1 << 6,
IBV_QP_AV = 1 << 7,
IBV_QP_PATH_MTU = 1 << 8,
IBV_QP_TIMEOUT = 1 << 9,
IBV_QP_RETRY_CNT= 1 << 10,
IBV_QP_RNR_RETRY= 1 << 11,
IBV_QP_RQ_PSN = 1 << 12,
IBV_QP_MAX_QP_RD_ATOMIC = 1 << 13,
IBV_QP_ALT_PATH = 1 << 14,
IBV_QP_MIN_RNR_TIMER= 1 << 15,
IBV_QP_SQ_PSN = 1 << 16,
IBV_QP_MAX_DEST_RD_ATOMIC = 1 << 17,
IBV_QP_PATH_MIG_STATE = 1 << 18,
IBV_QP_CAP = 1 << 19,
IBV_QP_DEST_QPN = 1 << 20
};
The warning is really an error, since neither the right hand side
"IBV_QP_ALT_PATH|IBV_QP_PATH_MIG_STATE" nor "0" is one of the enum
ibv_qp_attr_mask values, and is therefore not a valid member of that
data type. I'm not really sure there is a better way, since C does
not guarantee the order of bitfields. Anyway, since C permits enums
to be used wherever ints can be used, the right hand side
