[Patch, Fortran, 4.7] PR 18918 - Add initial support for a coarray communication library

[Tobias Burnus]

Steve Kargl wrote:
> On Sat, Mar 19, 2011 at 05:23:17PM +0100, Tobias Burnus wrote:
>> My idea is to place those library into libgfortran/caf. The user has to
>> compile them themselves and link it then to their "gfortran
>> -fcoarray=lib" compiled program. (Cf.
>> http://gcc.gnu.org/ml/fortran/2011-03/msg00003.html).
> [1] I don't understand what you mean by the above.  Are you saying that
> gcc would install caf.h, caf_mpi.c, etc in say
> lib/gcc/i386-unknown-freebsd9.0/4.7.0/libgfortran
> and a user would need to do
>
> gfortran -fcoarray=mpi file.f90 ${PATH}/lib/gcc/i386-unknown-freebsd9.0/4.7.0/libgfortran/caf_mpi.c
>
> to compile her code to use coarrays?

Well, the code is only in the GCC source code and not in the installed 
directory (as in your example); and the -fcoarray= argument is "lib" and 
not "mpi".

But the answer is: Essentially, yes. One has the same issue as with 
gfortran's -fexternal-blas and with GCC's -mveclibabi=<acml|svml>. 
Namely, there is a lot of system dependency. For BLAS there exists 
Netlib's and several vendor versions and also for ACML/SVML on might 
have different file names and library paths.

While the single-image library version could be directly compiled and 
linked, that's not possible with MPI. There exist too many MPI 
implementations and too much system dependence to do this automatically.

Thus, the procedure is usually the following; one compiles the file once 
- for real deployment, one would do something like the following (e.g. 
as HPC administrator or as Linux distributor):

mpicc -O2 -flto -c $GCC_SOURCE/libgfortran/caf/libgfortrancaf_mpi.c
ar rcs libgfortrancaf_mpi.a libgfortrancaf_mpi.o
cp libgfortrancaf_mpi.a  /usr/lib64/mpi/gcc/openmpi/lib64

(As a user with self-compiled gfortran, one would copy it, e.g., to 
$HOME/gcc-trunk/lib{,64}.)


And when compiling a coarray program, one simply specifies the library as in

mpif90 -fcoarray=lib *.f90 -lgfortrancaf_mpi


In the future, one could automatically generate the single-image library 
and - when passing some MPI-settings to ./configure - also a version for 
MPI, which would then be installed in, e.g., 
$prefix/lib64/gcc/x86_64-gnu-linux/4.7/. [1]

(For the shared-memory version [-fcoarray=shared] one will automatically 
link the library, but first the library implementation has to work, 
before one starts another construction site. The advantage for the 
shared-library version is that one has a known ABI for libpthread - and 
might be able to share some of the existing libgomp functions.)

If you have a better idea how one should handle the MPI-wrapper library, 
I would be interested. (Besides, I am looking for a full review of 
either the library or of the front-end patch ;-)

  * * *

>> >  (b) Are the libgfortrancaf.h, libgfortrancaf_mpi.c and
>> >  libgfortrancaf_single.c OK for inclusion at libgfortran/caf?
> Just a comment on names.  Since you are planning to install
> these in libgfortran/caf, please shorten the file names to
> caf.h, caf_mpi.c, and caf_single.c.  Consider this a friendly
> RSI prevention measure.

I was thinking of using the lib- prefix for linking as one should at the 
end generate a lib*.a file (cf. libgfortran.h). And I feared that 
libcaf.* might be ambiguous, if one places into $prefix/lib/. But I am 
fine with libcaf.h or with caf.h if you think that it is preferable.

Tobias

[1] Cf. Ralf's comments at 
http://gcc.gnu.org/ml/fortran/2011-03/msg00004.html