Jed Brown <j...@jedbrown.org> writes: > George Bosilca <bosi...@icl.utk.edu> writes: > >> Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As these >> languages are interoperable, and there is no explicit conversion function, >> it is safe to assume this is the case. Thus, is seems to me absolutely >> legal to provide the MPI-required support for DOUBLE PRECISION despite the >> fact that Fortran support is not enabled. > > Isn't that entirely dependent on the Fortran compiler? There is no > universal requirement that there be a relationship between Fortran > INTEGER and C int, for example.
In case it's not generally obvious: the compiler _and its options_. You can typically change the width of real and double precision, as with gfortran -default-real-8, and similarly for integer. (It seems unKIND if the MPI standard specifically enshrines double precision, but anyhow...) > Feature tests are far more reliable, accurate, and lower maintenance > than platform/version tests. When a package defines macros/symbols that > fail at run-time, it makes feature tests much more expensive. Even more > so when cross-compiling, where run-time tests require batch submission. Right, but isn't the existence of the compiler wrapper the appropriate test for Fortran support, and don't you really need it to run Fortran-related feature tests? I have an "integer*8" build of OMPI, for instance. It's a pain generally when build systems for MPI stuff avoid compiler wrappers, and I'd hope that using them could make possibly-unfortunate standards requirements like this moot. Would there be a problem with that in this case?
