Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Compile-time MPI_Datatype checking
From: Dmitri Gribenko (gribozavr_at_[hidden])
Date: 2012-10-19 18:11:44

On Thu, Oct 18, 2012 at 7:32 PM, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On Oct 7, 2012, at 2:25 PM, Dmitri Gribenko wrote:
>> I tried to follow your advice about Fortran datatypes and updated the
>> patch accordingly (attached). This patch is against OpenMPI 1.9.
>> Please review.
> Comments in the attached. Look for "*** JMS".

Thank you for the review! Please find attached an updated patch.

*** JMS The thought occurs to me that Fortran's built-in types
PRECISION will *always* exist if we are including Fortran support.
The other (LOGICAL1, LOGICAL4, ...etc.) are optional/compiler
extensions and may or may not exist. Regardless, the point is that I
wonder if we don't need these extra #defines (E.g.,
OMPI_HAVE_FORTRAN_CHARACTER) -- we could just use #if
OMPI_BUILD_FORTRAN_USEMPI_BINDINGS) (or have an abbreviation for

Thank you for the suggestion, I introduced OMPI_BUILD_FORTRAN_BINDINGS
into for this.

*** JMS Per my above ramble, CHARACTER and INTEGER (and others) are
built-in to Fortran, so we'll always have these if we're building
Fortran at all. So how about simplifying these cases a little;
perhaps something like:
*** JMS I think these "2foo" types might be able to be simplified per
my above ramble...?


*** JMS Can we do anything with ## to simplify these macros a bit,
perchance? (I haven't thought this through)

+OMPI_DECLSPEC extern struct ompi_predefined_datatype_t ompi_mpi_logical1
+ OMPI_ATTR_TYPE_TAG(ompi_fortran_logical1_t)
+ ;

I could not think of anything that could help to simplify that part.
All of these attributes are predicated on different conditions.

 typedef struct {
   ompi_fortran_real_t real;
   ompi_fortran_real_t imag;
-} ompi_fortran_complex_t;
+} ompi_fortran_complex_struct_t;

*** JMS I was initially curious as to why you renamed these, but now I
see: it's because we added the same names into Do we really
still need them here in I.e., aren't the
definitions the same?

They are different because macro names in are defined to
expand standard complex types' names (like float _Complex); there is
special syntax to access real and imaginary parts of these. Types in are custom structs that are layout-compatible with
standard complex types; real and imaginary parts can be accessed with
usual member access operators.

So, while we could change op_base_functions.c that uses these structs
to use standard syntax (and remove struct declarations), I doubt that
it is desirable. As far as I understand, one should be able to build
OpenMPI with a compiler that does not support standard complex types.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr_at_[hidden]>*/