Hi FX, > 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.
yes, I agree. This is already successfully done in some cases (e.g. for system_clock). > 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. Likely GFC_INTEGER_8 or int64_t or compatible. We have 32/64bit and -fdefault-integer-8 to deal with... Harald
