On Oct 7, 2012, at 2:25 PM, Dmitri Gribenko wrote:
>> Ok, this might get a little complicated. You'll probably need to use a pair of them (this is trunk only; it's different in v1.6 because we wholly revamped the trunk's Fortran support recently):
>> 1. You can see all the OMPI_HAVE_FORTRAN_<type>'s at the top of mpi.h.in. These indicate whether the Fortran compiler supports these types or not.
>> 2. We currently define *one* Fortran type in mpi.h.in: ompi_fortran_integer_t. It looks like we need to add the rest of them: ompi_fortran_<type>_t (these are all in opal/include/opal_config.h, but mpi.h is a standalone, user-includeable file, which is why it replicates a subset of all the configure-generated results). Here's a first stab at what I think will be needed in mpi.h.in:
> Hello Jeff,
I'm *so* sorry for the delay; I'm literally buried in SC deadlines. It's that time of year again... :-(
> I would like to continue this discussion. Corresponding changes in
> Clang are already in SVN and the feature should be released with the
> upcoming Clang 3.2.
> 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".
> Is there any chance we can get a less invasive (header-only, without
> autotools magic for Fortran datatypes support) change in the OpenMPI
Hmm. I'm not sure how to do that -- I don't know of any C compiler that has built-in #defines for what Fortran types exist.
I'm open to suggestions, though -- can you suggest an easier solution?
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/