Libgfortran ABI cleanup TODO list
libgfortran has used SymbolVersioning since version 4.3 (libgfortran.3.so), to maintain ABI compatibility among releases, making life easier for our users. The ABI was broken for version 7 (libgfortran.4.so).
We maintain below a TODO list of ABI cleanup projects, which we should address the next time the ABI is broken.
See ArrayDescriptorUpdate, which will break the ABI and thus give the opportunity to cleanup the ABI.
Move the character length hindden dummy (__len) to INTEGER(8) or size_t (as Intel does)? Pro: string.h et alia use size_t, allows longer strings. Con: Breaks API for old programs. -- See also the casting/valgrind issue of PR47552.
Change ALLOCATE,INTENT(OUT) handling, cf. PR41897
Remove function wrappers if possible, cf. PR47493
RECL= of the OPEN statement allows any INTEGER kind; however, effectively gfortran only supports INTEGER(4) PR44292
- For many intrinsics there are multiple implementations for different argument kinds. In many cases these should be replaced by a single implementation and having the frontend convert the arguments. E.g. fseek, isatty etc. Of course intrinsics with floating point arguments or that are otherwise performance sensitive must still be kept separate. Also, it should be noted that the current system with foo_i4 and foo_i8 works for F95 where intrinsics require an integer of default kind, in F2003 this restricitons has been lifted and most intrinsics should now accept integers of any kind the compiler supports. Hence doing intrinsics the old way with separate library functions leads to a combinatorial explosion for those intrinsics with multiple integer arguments.
- Combine the enum dtype (GFC_DTYPE_*) and enum bt (BT_*), perhaps using the type tags from the TR29113 descriptor. These enums are used throughout the library and the frontend too.
The front end should auto-deallcoate allocatable INTENT(OUT) variables in the callee (trans-decl.c) and not in the caller (trans-expr.c's gfc_conv_procedure_call); cf. PR41897
Font end: Remove the double-conversion of the BOUNDS of ASSUMED-SHAPE variables in the CALLER and in the CALLEE (lbounds always start at 1, unless something special is specified). Presumably not as trivial as it seems ... PR41911
- Restructure st_parameter_dt and st_parameter_common to consolidate some items, get rid of unneeded items, and figure out how to reuse the dtp structure from io call to io call so that less memory is used.
- Refactor the I/O to reduce overhead, particularly related to data_transfer_init and READ vs WRITE.
PR51802: Duplicate mangling for OOP symbols
- VTABLE: Use a size-type node (or at least ptrdiff_t) for "_size" instead of hard coding a kind-4 integer.
PR53971: Change the order in the CLASS container. Currently, it is: _data, _vtab. For arrays, _data is the class container. Thus, when passing an assumed/deferred-rank polymorphic array to an assumed-rank polymorphic dummy. Thus, the _data part needs to be a GFC_MAX_DIMENSIONS array - and, hence, assumed/deferred-shape arrays need to be copied to have a class container of the same size. The main reason is that class._vtab just matches "(vtab *) &class + sizeof(_data)". Hence, any attempt to change GFC_MAX_DIMENSIONS will lead to an ABI breakage. If the order in the class container were (_vtab, _data), one the dimension field of _data could be of variable length, avoiding the need for copy in and copy out. Additionally, one could later bump the maximally allowed GFC_MAX_DIMENENSIONS.
Wrong name mangling for procedure pointers PR52909