Hi Harald, > If we do not want to break the existing ABI, so that we can > link gfortran-13 and gfortran-14+(?) compiled code, we need > to keep _gfortran_get_command_i4 & friends, and introduce > new library functions that are able to handle the new > requirements.
I have been thinking about the large number of intrinsic implementations we have, with their naming conventions (_i4, _i8, etc). The standard seems to go in the direction of allowing more and more kind and type combinations (in general), and our approach dooms us to an explosion of the library in terms of number of functions. I believe this is in part because historically the front-end lowered most intrinsics directly into a function call. But we don’t have to continue doing that, and I would be in favour of limiting as much as we can the number of library functions, and handle the rest in the front-end. For example, we could have one library-side function called _gfortran_f2018_get_environment_variable with fixed integer types (probably int or size_t). Then the conversions are handled in the front-end. FX
