Re: [OMPI devel] u_int8_t

2011-01-10 Thread Jeff Squyres
Shrug. If they're not used anywhere, I'd whack them. Do we have configure tests for them, or just #define's? On Jan 10, 2011, at 7:51 PM, Eugene Loh wrote: > Why do > u_int8_t > u_int16_t > u_int32_t > u_int64_t > get defined in opal_config.h? I don't see them used anywhere in the > OMPI/

[OMPI devel] u_int8_t

2011-01-10 Thread Eugene Loh
Why do u_int8_t u_int16_t u_int32_t u_int64_t get defined in opal_config.h? I don't see them used anywhere in the OMPI/OPAL/ORTE code base. Okay, one exception, in opal/util/if.c: #if defined(__DragonFly__) #define IN_LINKLOCAL(i)(((u_int32_t)(i) & 0x) == 0xa9fe) #

Re: [OMPI devel] Datatype question

2011-01-10 Thread Jeff Squyres
Brian -- is this enough information to complete the blocker defect https://svn.open-mpi.org/trac/ompi/ticket/2656? On Dec 21, 2010, at 2:54 PM, George Bosilca wrote: > Anyway, back to your question. The MPI and OPAL datatypes uses the same > indexes, for all the OPAL predefined types. Several

Re: [OMPI devel] Problem with attributes attached to communicators

2011-01-10 Thread Pascal Deveze
Dave, Your proposed patch does not work when the call to MPI_File_open() is done on MPI_COMM_SELF. For example, with the romio test program "simple.c", I got the fatal error: mpirun -np 1 ./simple -fname /tmp//TEST Fatal error in MPI_Attr_put: Invalid keyval, error stack: MPI_Attr_put(131): MP