Hello all, with respect to "Problem A" I have the following (preliminary, given my state of knowledge) opinion: Given the standard's *present* provisions (which makes an explicit formal distinction between SEQUENCE and BIND(C)) an implementation wishing to provide C interop faces the following situation: (1) SEQUENCE types with interoperable ultimate components have the same storage layout as BIND(C) types of the same structure (2) SEQUENCE types do not have the same storage layout as said BIND(C) types In case (1), an implementation may be liberal and accept (like e.g., ifort does) non-conforming code. The latter may involve SEQUENCE actual arguments in BIND(C) calls, or BIND(C) type components in SEQUENCE types, or SEQUENCE components in BIND(C) types. In case (2), the implementation has no choice but to strictly follow the standard's provisions, and reject any attempt to intermix SEQUENCE with BIND(C). I don't know which implementations are of class (2), but any attempt to make use of SEQUENCE legal with BIND(C) via the TR would need to exclude such implementations. The only thing that could conceivably be done for such implementations is to allow SEQUENCE types as (non-VALUE) actual arguments in BIND(C) interfaces, and require that the corresponding C prototype is a void *. This would then on the C side force a programming style like typedef struct { ... } mytype; #ifdef CFI_SEQUENCE_MATCHES_C void foo(mytype *obj) { // reference obj via type components } #else void foo(void *obj) { // reference obj components via accessors which must be written in Fortran } #endif Regards Reinhold

-----Ursprüngliche Nachricht----- Von: Rolf Rabenseifner [mailto:[email protected]] Gesendet: Donnerstag, 14. April 2011 16:23 An: John Reid; [email protected] Cc: Bader, Reinhold; Craig Rasmussen; Bill Long; N.M. Maclaren; Jeff Squyres; MPI-3 Fortran working group Betreff: Derived-data, a new/late comment on Fortran WG5 ballot N1846

Dear John, dear members of the WG5 and J3 Fortran committees,

I'm sorry that with this additional comment on problems regarding derived types, I missed the deadline of the N1846 ballot for the N1845 draft of the TR 29113 on extensions on Fortran-C interoperability.

It looks like that there are two problems with derived types and the Fortran- MPI-compatibility with a background in the Fortran-C-interoperability.

Problem A: Sequence derived types in the MPI routine interfaces, which are declared with BIND(C); this problem occurs with the new MPI handles and MPI statuses.

Problem B: Derived type, SEQUENCE derived type, and BIND(C) derived type as actual user buffers for TYPE(*),DIMENSION(..) dummy arguments in BIND(C) MPI routine interfaces.

Problem C: Based on problem B we have the question whether the new TYPE(*),DIMENSION(..) dummy arguments in BIND(C) MPI routine interfaces really allow all actual arguments that were possible with implicit interfaces or with explicit interfaces in combination with pragmas like !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf and !$PRAGMA IGNORE_TKR buf