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: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-10-26 11:37:12


On Oct 19, 2012, at 6:11 PM, Dmitri Gribenko wrote:

> Thank you for the suggestion, I introduced OMPI_BUILD_FORTRAN_BINDINGS
> into mpi.h.in for this.

Excellent.

> *** 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.

w00t

> *** 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.

Ok. I mucked around a little and couldn't figure out a better way, either.

> 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.

Correct.

This all now looks good to me (i.e., v5 of the patch); many thanks for your perseverance and patience.

For me to commit this, can you do two things:

1. I hate to do this, but this is more than a "trivial" patch that we could accept without attribution. Can you do one of two things:
   1a. Sign a contributor agreement (almost identical to the Apache contributor agreement): http://www.open-mpi.org/community/contribute/
   1b. Send a v6 of your patch to this public mailing list with a BSD-compatible license at the top, thereby releasing your patch under that license (which is compatible with OMPI's).

2. Give me a short description that I can use to put into the README / FAQ / etc. about what this functionality does, what prerequisites are needed (e.g., version of clang, etc.).

Many thanks!

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/