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
