On Feb 9, 2016, at 12:21 AM, George Bosilca <bosi...@icl.utk.edu> wrote:
>
> Sorry to spoil the fun here, but this proposal is a very bad idea. It is
> mandated by the MPI standard, page 25 line 27 (v3.1), not only to provide all
> predefined datatypes, but to have support for them. There are optional
> datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base predefined
> datatype for MPI_2DOUBLE_PRECISION) is not one of them.
I don't quite follow the logic here.
The mpif.h interface is mandated by The MPI spec. If you're building Open MPI
on a platform without a Fortran compiler, then by definition, you don't get a
compliant MPI implementation because you're missing a key requirement (i.e., a
Fortran compiler). We -- the Open MPI developers -- have chosen to enable this
non-conformant scenario because there are valid use cases for it with our users.
Meaning: there is no question that this is not conformant behavior. Saying
that we can't do it because it is not conformat is tautological.
What we're discussing is how to make the behavior useful to end users in this
already-defined-to-be-non-conformant situation.
Also, note that Open MPI disables a bunch of other datatypes if they can't be
supported -- just search for the use of the macro UNAVAILABLE in
ompi/datatype/ompi_datatype_internal.h (which lead to run-time failures if they
can't be used). The question here is whether that should be a compile time vs.
run time failure. I think there's good arguments for making them be compile
time failures, if possible.
> Now we can argue if DOUBLE PRECISION in Fortran is a double in C.
FWIW:
1. MPI-3.1 Annex A p674 states that MPI_DOUBLE_PRECISION is a Fortran datatype
that corresponds to the Fortran type "DOUBLE PRECISION".
2. MPI-3.1 5.9.4 p180 declares MPI_2DOUBLE_PRECISION to be a pair of Fortran
DOUBLE PRECISION variables.
Whether or not DOUBLE PRECISION is exactly equivalent to a C double is an
entirely different question.
> As these languages are interoperable,
That's an extremely broad statement. :-)
To be pedantic: there are many things in each language that do not exactly
interoperate with each other. Indeed, F08 explicitly added a bunch of things
to the Fortran language to precisely allow interop between C and Fortran (e.g.,
continued enhancements to the definitions of BIND(C) and related things). But
there are still many things between that two that are not identical -- the two
languages do not have a 1-to-1 correspondence for every one of their features.
> and there is no explicit conversion function, it is safe to assume this is
> the case.
Whether or not Fortran's DOUBLE PRECISION is exactly equivalent to a C double
(and whether a pair of Fortran DOUBLE precision variables is exactly equivalent
to a pair of C double variables) is not something you can assume.
Easy case to pick on: what if the user compiles their Fortran program with -i
8? (i.e., integers are double their normal size) We tell Open MPI users that
this scenario is supported, but only if they configure Open MPI with
FCFLAGS="-i 8" so that Open MPI's configure can figure out that INTEGER is 8
bytes long (and therefore doesn't correspond to a C int). ...and so on.
There's a similar compiler flag for floating point values ("-d 8"? I don't
remember offhand), that makes the assumption that Fortran DOUBLE PRECISION ===
C double a bad one.
Also, we've definitely run into cases in the past where the alignments of
Fortran datatypes are different than the alignments of C datatypes.
In short: the only way that we can *know* that a Fortran datatype is equivalent
to a C datatype is to actually *test* it. Given that Open MPI already disables
a bunch of datatypes when it can't support them, it's not unreadable to
a) disable all Fortran types when Open MPI was not configure with a Fortran
compiler, and
--> OR Provide the option for the user to choose between
"You didn't configure with a Fortran compiler, so I'll assume C
types===Fortran types" (i.e., some of today's behavior), and
"You didn't configure with a Fortran compiler, so I'll disable all
Fortran types"
b) see if we can make unsupported datatypes be compile-time failures instead of
run-time failures.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
