On Mar 30, 2014, at 2:43 PM, W Spector <w...@earthlink.net> wrote:

> The mpi.mod file that is created from both the openmpi-1.7.4 and 
> openmpi-1.8rc1 tarballs does not seem to be generating interface blocks for 
> the Fortran API - whether the calls use choice buffers or not.

Can you be a bit more specific -- are there *no* interface blocks in the mpi 
module? Or just less than expected?

In 1.7.x (and 1.8), all versions of gfortran should be using the "tkr" 
implementation of the mpi module, which should only include MPI subroutines 
that have no choice buffers (e.g., MPI_INIT, MPI_FINALIZE, ... etc.).

> I initially tried the default gfortran on my system - 4.7.2.  The configure 
> commands are:
> 
> export CC=gcc
> export CXX=g++
> export FC=gfortran
> export F90=gfortran
> ./configure --prefix=/home/wws/openmpi_gfortran  \
>    --enable-mpi-fortran --enable-mpi-thread-multiple \
>    --enable-mpirun-prefix-by-default  \
>    2>&1 | tee config.gfortran.out
> 
> The relevant configure output reads:
> 
> ....
> checking if building Fortran mpif.h bindings... yes
> checking for Fortran compiler module include flag... -I
> checking Fortran compiler ignore TKR syntax... not cached; checking variants
> checking for Fortran compiler support of TYPE(*), DIMENSION(*)... no
> checking for Fortran compiler support of !DEC$ ATTRIBUTES NO_ARG_CHECK... no
> checking for Fortran compiler support of !$PRAGMA IGNORE_TKR... no
> checking for Fortran compiler support of !DIR$ IGNORE_TKR... no
> checking for Fortran compiler support of !IBM* IGNORE_TKR... no
> checking Fortran compiler ignore TKR syntax... 0:real:!
> checking if building Fortran 'use mpi' bindings... yes
> checking if building Fortran 'use mpi_f08' bindings... no
> ....

That looks right.

> I have also tried using a version of the 4.9 trunk that I generated from a 
> March 18th, 2014 snapshot of the gcc trunk.  This latter compiler supports 
> some of the TS 29 features.  (I set the latter by setting PATH to find the 
> 4.9 compilers first.  I also set the F90 and FC environment variables to 
> point to the 4.9 compiler.)
> 
> make clean
> export PATH=/usr/local/gcc-trunk/bin:$PATH
> export CC=gcc
> export CXX=g++
> export FC=/usr/local/gcc-trunk/bin/gfortran
> export F90=/usr/local/gcc-trunk/bin/gfortran
> ./configure --prefix=/home/wws/openmpi_gfortran49  \
>    --enable-mpi-fortran --enable-mpi-thread-multiple \
>    --enable-mpirun-prefix-by-default  \
>    2>&1 | tee config.gfortran49.out
> 
> The configure output is identical to the 4.7 compiler.  Note that it did NOT 
> recognize that gfortran now supports the !GCC$ ATTRIBUTE NO_ARG_CHECK 
> directive, nor did it recognize that gfortran also accepts 'TYPE(*), 
> DIMENSION(*)'.

That's correct, too, but for a few obscure reasons:

1. I think there's been some churn on the gfortran HEAD recently; I had an 
older version that worked (I'm afraid I don't know/remember the exact date of 
the checkout), but I was comparing notes with the MPICH guys doing the Fortran 
module stuff and they had a slightly newer gfortran checkout that *didn't* 
work.  Then I updated my gfortran checkout to be slightly newer than theirs, 
and it *did* work.

I realize this is a a very fuzzy, anecdotal story with very few details, but 
the point is that I think there's been some instability at the gfortran 
development head (which is probably to be expected -- it's the development 
head, after all).

2. TYPE(*), DIMENSION(*) is not sufficient for MPI choice buffers -- it doesn't 
allow scalars.  So we don't use it.

3. There's currently a bug in OMPI since 1.7.5 that affects the new gfortran 
4.9 usage that I haven't had a chance to fix yet (it isn't super-high-priority 
because gfortran 4.9 isn't released yet).  Hence, OMPI still doesn't use the 
gfortran 4.9 goodness so that it avoids this bug.  :-\  See 
https://svn.open-mpi.org/trac/ompi/ticket/4157 for more details.

> I have also verified with strace that the proper mpi.mod file is being 
> accessed when I am trying to USE the mpi module.
> 
> I have not dug into the openmpi code yet.  Just wondering if this is a known 
> problem before I start?  Or did I do something wrong during configure?


If you're using subroutines like MPI_INIT and other non-choice-buffer 
interfaces, they should be there in mpi.mod.

Let me know if they're not -- we can dig further.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Reply via email to