Require ABI compatibility in ISO_Fortran_binding.h

[awvwgk]

Following a discussion on the Fortran-lang discourse (https://fortran-lang.discourse.group/t/2652) about ABI compatibility with ISO_Fortranbinding.h, I want to open this thread to discuss whether it is possible / feasible to require ABI compatibility for the `CFI*` procedures and descriptors in a future revision on the standard.

Motivation

• C provides a remarkable ABI compatibility across different compilers, which is available in Fortran via the Fortran 2008 and earlier bind(c) and iso_c_binding constructs
• extending this promise of ABI compatibility to the CFI_* procedures and descriptors would allow to develop robust interfaces from other languages to Fortran, which can work for all available conforming Fortran compilers
• a language that cannot parse the C header should be able to define an interface via the CFI_* procedures, e.g. it should be possible with the Fortran 2008 C intercompatibility features to define the CFI_* descriptors and procedures independently of the actual vendor

Proposed changes

• define order of components in CFI_* descriptors
• define that the CFI_* procedures must be implemented as functions and cannot be macros which resolve to different functions
• define a robust way to store vendor specific data without interfering with ABI compatibility (e.g. as void* pointer in descriptor)

This is my first time contributing here. I'm looking forward to your feedback.

[klausler]

You would also need to:

• define specific integer values for all of the macros for CFI_type_XXX codes, attributes, &c.
• define specific types for all of the CFI typedefs (CFI_rank_t, CFI_index_t, CFI_attribute_t, &c.)
• define specific values for the CFI_XXX error codes
• convince vendors to make necessary incompatible changes to their products
• convince their users to recompile their codes

See https://github.com/llvm/llvm-project/blob/main/flang/include/flang/ISO_Fortran_binding.h for a complete example.

[awvwgk]

• convince vendors to make necessary incompatible changes to their products
• convince their users to recompile their codes

Indeed, this is an issue. It would be ABI breakage rather than API breakage, given that ABI compatibility is not guaranteed at the moment it might be feasible and still be a backwards compatible change in the standard. Correct?

[klausler]

• convince vendors to make necessary incompatible changes to their products
• convince their users to recompile their codes

Indeed, this is an issue. It would be ABI breakage rather than API breakage, given that ABI breakage is not guaranteed at the moment it might be feasible and still be a backwards compatible change in the standard. Correct?

I don't understand your question; but changing any of the values, types, or component orders in a compiler's ISO_Fortran_binding.h file is going to be a change that would prevent previously-compiled code from successfully linking with newly-compiled code when C interoperability is being used. (Or even when it is not -- f18 uses this "interoperable" descriptor as its only Fortran data descriptor as well.)

If J3 had done a better job defining ISO_Fortran_binding.h with specific types, values, and struct layouts, we would have be able to use interoperable interfaces to link Fortran code compiled with different Fortran compilers, not just with C. So what you propose would be great, had it been done 14 year ago. At this point, though, it seems vanishingly unlikely that you would be able to convince any vendor to change their ISO_Fortran_binding.h file.

[ivan-pi]

Here's how the CFI_cdesc_t struct looks like in a few major compilers:

// gfortran                 // flang                    // NAG                      // Intel         
void *base_addr;            void *base_addr;            void *base_addr;            void * base_addr;
size_t elem_len;            size_t elem_len;            size_t elem_len;            size_t elem_len;
int version;                int version;                int version;                int version;
CFI_rank_t rank;            CFI_rank_t rank;            CFI_rank_t rank;            CFI_attribute_t attribute;
CFI_attribute_t attribute;  CFI_type_t type;            CFI_type_t type;            CFI_rank_t rank;
CFI_type_t type;            CFI_attribute_t attribute;  CFI_attribute_t attribute;  CFI_type_t type;
CFI_dim_t dim[];            unsigned char f18Addendum;  size_t len,offset;          intptr_t intel_flags;
                            CFI_dim_t dim[];            int64_t *dtp;               intptr_t intel_reserved1;
                                                        void *sig;                  intptr_t intel_reserved2;
                                                        void *reserved;             CFI_dim_t dim[];
                                                        int64_t ireserved;
                                                        CFI_dim_t dim[];

Essentially none of them are compatible.

[reinh-bader]

Also there is a fundamental roadblock here in that different Fortran compilers might have different C companion processors that might be non-compatible.