Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Fortran MPI module and gfortran
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2014-04-07 16:43:53


On Mar 30, 2014, at 2:43 PM, W Spector <w6ws_at_[hidden]> 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
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/