Hello all, hi Ralf and Jorge,

The attached patch causes libgfortran/ also to build 
libgfortran/caf/single.c, which will be installed as 
$PREFIX/.../target-triplet/gcc-version/libcaf_single.a.

Build and tested on x86-64-linux.
OK for the trunk?

  * * *

As a possible enhancement, one could also automatically build mpi.c 
using AX_MPI. However, one needs to think about whether one should - and 
if so, when the build should be enabled. (Cf. 
http://www.gnu.org/software/autoconf-archive/ax_mpi.html and 
http://gcc.gnu.org/ml/fortran/2011-03/msg00004.html)  -- One issue I see 
is that one might end up using the wrong libcaf_mpi if one automatically 
compiles mpi.c and places it into the lib*/gcc/<triplet>/<version> 
directory.

  * * *

Regarding the test suite: I think I will add an extra directory - such 
as gfortran.dg/coarray -, in which by default the files are compiled/run 
with the flag -fcoarray=single and -fcoarray=lib -lcaf_single. 
Optionally, one additionally tests -fcoarray=lib with some 
parallelization library (e.g. libcaf_mpi.a). That will happen if some 
variable is set; the setting happens via site.exp and can be overridden 
by some environment variables.

  * * *

Regarding the comments by Ralf and Jorge/Lisandro:

My idea was to either not build libcaf_mpi - or only with the default 
MPI compiler (cf. AX_MPI above) and only statically. The current plan is 
to make building libcaf_mpi simple such that an interested (Linux) 
distributor or a system admin or a user can simply compile it with their 
favourite compiler - cf. http://gcc.gnu.org/wiki/CoarrayLib. If a system 
admin or user prefers it, they can also build a shared library (.so, .dll).

The reason that a static libcaf_mpi is should be sufficient is that 
there is typically only a single MPI installed on a system; if one wants 
to use a different one - e.g. on a different system - one can simply 
relink. Only for the special case that one wants to easily switch the 
MPI library, one needs a dynamic library. However, that's a very special 
case - thus the burden of creating a shared library can be put on the admin.


Regarding Ralf's "I think one of the most important things is that you 
allow to override both the running of mpif90 and the mpiexec commands":

I think your comment that's with regards to the test suite and I concur.

I am not sure whether one should have a default value. While "mpiexec -n 
2" will usually work, compiling is more difficult: Calling "mpif90" will 
usually invoke the compiler specified when building mpif90 - and not the 
just build gfortran/f951; but the latter should be tested when making 
"make check-gfortran". Thus, I think one probably should add a 
$FCFLAGS/$LDFLAGS options which contains the value of "mpif90 -show" (or 
however it is called in your MPI implementation). I therefore think one 
should have two or three site.exp/environment settings: The compile/link 
flags and the run command.

Regarding "qsub", "msub" or "llrun": I assume most testers will use 
mpiexec directly, which will then typcially use 2 to 4 local processes 
(shared-memory MPI). Using a queuing system is more complicated as the 
submit commands will typically return before the completion of the job 
and the output will typically be written into a file. I think one could 
work around that by writing a mpiexec replacement wrapper which submits 
the job and cats the output to stdout/stderr. One also might need to 
adjust the timeout settings. Hence, I think queued processing will 
probably not be done for "make check-gfortran" but only manually - using 
either the dg-run programs or some other test or real-world coarray 
program. But with a wrapper, it should work.


Ralf: "The MPI implementations I know all have pairwise incompatible ABIs"

Well, as written above, the ABI of the coarray program is defined and 
independent from the MPI ABI - thus the difference is only in libcaf. 
Therefore, if libcaf is dynamically linked, switching the MPI 
implementation and simultaneously libcaf_mpi.so should work. But as 
written above, I think that is something the distributor/admin/user 
should do and not GCC itself.

(Lisandro/George:) 'A dynamic library "libcaf_mpi.so" is not linked with 
MPI, but uses the dlopen() and dlsym(), to load and access the contents 
of a specific "MPI-linked" dynamic library 
"libcaf_mpi_{mpich2|openmpi|other}.so". This way "libcaf_mpi.so" does 
not depend on any MPI implementation'

I think that's overengineered. Having a simple libcaf_mpi.a in the path 
- e.g. in the $MPI/lib directory - should be the best for most typical 
usage. Having at the same location a libcaf_mpi.so will even allow 
dynamic switching. I think the main usage for a dynamically linked 
version is for closed-source software.

(Side note: I have never switched the MPI implementation on the same 
system and I have simply recompiled the whole program on different systems.)

Tobias