TS 29113 status report

[Tobias Burnus <burnus at net-b dot de>]

Dear all,

I think I should give some status report regarding the Technical 
Specification (TS) 29113 on Further Interoperability of C with Fortran â 
with regards to GCC/gfortran.

(1) The specification itself

TS 29113's DTS ballot has been initiated; the ballot results should be 
available in August, minor edits are scheduled for September and the 
final publication for November.
The DTS draft is available at 
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1917.pdf


(2) GCC/gfortran

Everything is already implemented, except for the points mentioned 
below. (Sorry, the list below is not completely ordered, but I try to 
mention some places which require attention; some might actually turn 
out to be already correctly implemented.)


a) Documentation

gfortran's documentation has to updated to include the changes of TS 
29113 (in the TS status section and the interoperability section)


b) Array descriptor

For the full implementation of TS 29113, a new array descriptor is 
required, which can also handle (scalar, array) character (sub)strings, 
gets passed the correct lower bound etc. Those parts have to be checked 
after/while the array descriptor is implemented.

(Current "Fortran-dev" branch status: The dimension triplet has been 
converted to the TS 29113 version, but there still one dozen test-case 
failures. After fixing those, the next big step is to get rid of the 
"offset" field. Then, the rest can be converted. The branch has been 
updated today, i.e., it can also be used for testing assumed-rank arrays.)


c) Assumed type, RANK, ASYNCHRONOUS, C_PTRDIFF_T

Assumed types are available since March with no known issues [but see 
also (d)]. RANK should be fully working, c_ptrdiff_t has just been 
added, and ASYNCHRONOUS should be also implemented (since 4.6) according 
to TS29113.


d) Assumed-rank arrays

The basic support is has been implemented, however, there are still some 
loose ends:

* ubound(x), lbound(x) and shape(x) do not work yet (return a zero-sized 
array, which is only okay for scalars) - size() and lbound/ubound with 
dim= work.
* Passing a noncontiguous assumed-rank array to a contiguous 
assumed-rank dummy doesn't work; that includes passing a class to type. 
[There could be a general problem with "CONTIGUOUS" polymorphic arrays.]
* There might be issues with zero-sized arrays and with assumed-size (!) 
arrays
* There might be issues with regards to interface checking (e.g. for 
dummy procedure), where assumed rank is regarded as identical to any 
other array, which wouldn't make sense. There might be the same issue 
regarding assumed types.
* One needs to check whether c_sizeof(assumed-rank) works (and that 
type(*) is rejected; similarly for storage_size and sizeof.)
(* And: when implementing CLASS(*), it also has to support assumed-rank 
arrays.)


e) C binding of procedures

* Allow allocatable/pointer dummies. Note that this implies support for 
deferred-length strings and for scalars, all of which have to be passed 
as descriptor. (For the character length, see above.)
* Allow passing nonallocatable/nonpointer strings (assumed length): This 
feature works also with scalars, assumed-size/explicit-size array 
dummies (internally always a descriptor is used). Note: When implemented 
in Fortran, the lower-bound has to work correctly with, e.g. 
"str(2:5,5:*)", substring arrays, assumed-size as actual argument to 
assumed-size dummies.
* Handle INTENT(OUT) correctly and add constraint checks regarding 
finalizers, default initializers, â
* Check whether the lower_bound has to be set correctly.
* Not a TS issue, but older: The binding-name check is too strict 
(multiple interfaces for the same proc should be allowed â under some 
conditions) and for COMMON, not the C binding name but the Fortran name 
is used for diagnostics. (See Bugzilla.)


f) C-binding Intrinsic functions

* is_contiguous is missing. That's actually not a TS29113 function, but 
a Fortran 2008 one.
* c_funloc, c_f_procpointer, c_f_pointer: Constraints have be relaxed
* c_sizeof (F2008 issue): There are still some bugs, see Bugzilla
* c_loc: This beast seems to be completely broken, e.g. "c_loc(A(5))" 
passes the address for A(1); if "A" is a noninteroperable assumed-shape 
array, A(1) is (wrongly) rejected. There are plenty of bug reports. 
(Handling of non-length-1 strings in relation to c_f_pointer)


(3) Message Passing Interface (MPI) 3 â a user of TS29113 features

The MPI 3 draft* uses for its "mpi3" module "type(*), rank(..)", which 
not only allows full argument checking for all arguments except of those 
"void *buffer" ones, but it also allows MPI to handle arrays with 
strides; the stride handling avoids memory and (for asynchronous 
communication) timing/memory-access issues due to the copy in/copy out 
of arguments.


The "mpi3-fortran" branch of the MPI implementation "Open MPI"**

- For other compilers, some means exist and are used to disable TKR 
checking for designated arguments. (gfortran doesn't allows this (except 
with an array descriptor via assumed ranks.)

A simple "type(*), dimension(*)" doesn't allow for scalars; using 
generic names is possible, but requires one interface per rank, which 
gives for two arguments 32 combinations (rank 0 to F2008's maximal rank 
of 15). The question is whether gfortran should also add a special 
directive, whether F2015 will provide a solution, or whether one simply 
ignores the issue.

- "type(*), dimension(..)" is not yet supported in the Open MPI branch, 
but they (Craig/Jeff) might try it with gfortran's implementation; 
however, as gfortran doesn't use TS29113/ISO_Fortran_binding.h's 
descriptor, I am not sure whether they will defer the implementation 
until it is available.

* Recent MPI 3 draft: http://www.unixer.de/sec/mpi-report-r1300.pdf
** Open MPI branch: https://bitbucket.org/jsquyres/mpi3-fortran/


Tobias