On 07/07/2011 01:35 PM, Mikael Morin wrote:
if (type == CAF_REGTYPE_COARRAY_STATIC)
{
This will return the same error (memory allocation failure) as in the case
just above. Is this expected or should it have an error of its own?
I think it is OK in either case. CAF_REFTYPE_COARRAY_STATIC is an
automatic allocation for static coarrays, e.g.
REAL, SAVE :: my_coarray(1000,1000,10)[*]
is allocated at startup (via a constructor) while the other case is for
allocatable coarrays of the form
REAL, ALLOCATABLE :: my_alloc_coarray(:, :, :)[:]
ALLOCATE (my_alloc_coarray(1000,1000,10)[*])
I admit that it is might be not obvious to the user that there is an
explicit allocate in the first case. However, one allocates memory in
either case and, thus, one could leave the message as is. In particular,
I would assume that on most systems, the size of static coarrays is
small enough that the message does not trigger.
However, if you think that the message could be clearer, I could also
change it.
+ msg = "Failed to allocate coarray - stopped images";
Also I'm wondering whether it would be pertinent to share the error handling
between single.c (one error) and mpi.c (2 or 3 errors) as the codes are very
close (with an interface such as handle_error (int *stat, char *errmsg, int
errmsg_len, char *actual_error)).
The question is where to handle it; in principle, single.c and mpi.c are
completely separate files - and both might be compiled by the
user/system administrator, contrary to the rest of GCC. Well, single.c
is actually automatically compiled as static library and installed as
libcaf_single.a. The MPI version is never compiled automatically.
Thus, anyone who wants to use gfortran with coarrays (based on mpi.c),
has to do:
a) Fetch libcaf.h and mpi.c
b) Compile mpi.c, e.g., using mpicc -g -O2 -c mpi.c
c) Link the such generated mpi.o (or libcaf_mpi.a) to the Fortran program.
As the user/sysadmin as to do the compiliation himself, I would like to
make it as easy as possible. The current idea is to have just a single C
file plus a header file and no further dependency. Other communication
backends could be added by simply creating a new file and implementing
the library calls.
Thus, I do not see how one could best share single.c and mpi.c error
messages. But if you have a good idea, I am open to change the current
implementation.
(See also http://gcc.gnu.org/wiki/CoarrayLib )
Build and regtested on x86-64-linux.
OK for the trunk?
The above is nitpicking, and I leave the final decision to you and Daniel, so
the patch is basically OK with the two indentation nits fixed.
I have now committed the patch with only the nits fixed (Rev.175966).
But given that the coarray support - especially with regards to the
library - is still in a flux, we can still change everything, including
the ABI of the library and the file organization. I am sure that not all
design decisions are optimal.
Thanks for the review!
Tobias
