[Patch, Fortran] Add STAT_STOPPED_IMAGE to SYNC ALL / SYNC IMAGES

Tobias Burnus burnus@net-b.de
Fri Jul 8 20:56:00 GMT 2011


Janne Blomqvist wrote:
>> +      char msg[50];
>> +       len = sprintf (msg, "ERROR: Image %d is stopped", caf_this_image);
>>
>>
>> Thus, I would prefer to use snprintf. The latter has the disadvantage that
>> not all systems support it, but I think all systems of interest do, if not
>> we can still modify it. (On MinGW __mingw_snprintf is preferred, but for
>> simple %d and %s, also Microsoft's snprintf should be sufficient.)
> In libgfortran.h we have some macros which allows us to use snprintf()
> (or __mingw_snprintf() aliased as snprintf()) everywhere, falling back
> to sprintf() if snprintf() is not available. Thus there is no need to
> clutter the rest of the code with #ifdefs.

The problem with the libgfortran.h macros is: They require configure. If 
possible, I would avoid writing an maintaining yet another configure 
script - and I think also users prefer to simply grab two files 
(libcaf.h and mpi.c) and just compile them.

Thus, I would like to stress again: libgfortran/caf/mpi.c is never 
compiled when building GCC. As it depends on the MPI installation of the 
GCC user, it needs to be compiled on the system of the user - by the 
user (or the sysadmin). Thus, unless we require every user of 
MPI-coarray gfortran to configure the whole of GCC, we need to make it 
possible to simply generate mpi.o (or libcaf_mpi.a).

That's currently done by downloading two files and running "mpicc -g -c 
-O2 mpi.c", as described at 
http://gcc.gnu.org/wiki/CoarrayLib#Obtaining_and_Compiling_the_Coarray_Communication_Libraries

That's the reason that I do not share headers with 
gcc/fortran/libgfortran.h, that's the reason I use default data types, 
and it's also the reason that I want to use "snprintf" directly.

Hence, unless there is a very compelling reason, I oppose adding 
configure dependency or including other header files.


[Regarding: "Re: [Patch, Fortran] Add stat=/errmsg= support to 
_gfortran_caf_register"]

Janne Blomqvist wrote:
> One minor thing is that one should use gfc_charlen_type_node
> (frontend) and gfc_charlen_type (library) for string lengths instead
> of int. (Currently gfc_charlen_type is a typedef for int, but if this
> is at some point changed to size_t, as has been discussed, then it's
> easier if one needs only to change a few places.)

I think for caf it should not really matter: Error strings should never 
exceed "int" and as the string size is passed by value, casting is no 
problem. However, one could add a typedef to libcaf.h, if you think that 
it makes life easer.

Tobias

PS: libgfortan/caf/single.c is automatically compiled and installed (as 
libcaf_single.a) when building libgfortran - as it does not have any 
special dependency.



More information about the Fortran mailing list