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
CHARACTER, COMPLEX, LOGICAL, INTEGER, REAL, DOUBLE COMPLEX, and DOUBLE
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_MPIFH_BINDINGS ||
OMPI_BUILD_FORTRAN_USEMPIF08_BINDINGS ||
OMPI_BUILD_FORTRAN_USEMPI_BINDINGS) (or have an abbreviation for
that)...

Thank you for the suggestion, I introduced OMPI_BUILD_FORTRAN_BINDINGS
into mpi.h.in 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...?

Simplified thanks to OMPI_BUILD_FORTRAN_BINDINGS.

*** 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
+#if OMPI_HAVE_FORTRAN_LOGICAL1
+ OMPI_ATTR_TYPE_TAG(ompi_fortran_logical1_t)
+#endif
+ ;

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;
 #endif

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

They are different because macro names in mpi.h.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
ompi_config.h.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.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr_at_[hidden]>*/