On Thu, Oct 18, 2012 at 7:32 PM, Jeff Squyres <jsquy...@cisco.com> 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 <griboz...@gmail.com>*/
ompi-v5.patch
Description: Binary data
