Aw: Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted

[Harald Anlauf]

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