libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted

libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted

[Harald Anlauf]

Dear all,

in Fortran 2018 a few intrinsics were extended and now support
additional optional arguments.  See PR 85836 for the meta-bug,
and in particular:

96583 - get_environment_variable
96584 - get_command
96585 - get_command_argument

with an optional ERRMSG.

How are we going to deal with this?

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.

Do we have recommendations for a naming scheme?
Like _gfortran_F2018_get_command_i4
or _gfortran_get_command_F2018_i4, or better?

Would it be sufficient to update gfortran.map suitably?
Or do we need to bump something else?

And would that be fine, given that 14-development is in stage-3?
Or rather wait for the next stage-1?

Thanks,
Harald

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

[FX Coudert]

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

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

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

[FX Coudert]

> Likely GFC_INTEGER_8 or int64_t or compatible.  We have 32/64bit and -fdefault-integer-8 to deal with…

That’s why I am suggesting either “int” or “size_t”, i.e., a well-defined C type. Means we don’t have to deal with -fdefault-integer.

FX

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

[Steve Kargl]

On Tue, Dec 19, 2023 at 09:07:08PM +0100, Harald Anlauf wrote:
> Dear all,
> 
> in Fortran 2018 a few intrinsics were extended and now support
> additional optional arguments.  See PR 85836 for the meta-bug,
> and in particular:
> 
> 96583 - get_environment_variable
> 96584 - get_command
> 96585 - get_command_argument
> 
> with an optional ERRMSG.
> 
> How are we going to deal with this?

At one time, we kept track of things that would break 
libgfortran's ABI on the wiki.  You can find the list
at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup.
This could be old and moldy as I haven't checked in
on ABI changes in a long time.

> 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.
> 
> Do we have recommendations for a naming scheme?
> Like _gfortran_F2018_get_command_i4
> or _gfortran_get_command_F2018_i4, or better?

The only convention that I can recall is the 
_gfortran_ prefix and the kind type suffix _i4.

> Would it be sufficient to update gfortran.map suitably?

If you add a new symbol, then yes, gfortran.map would 
need to be updated to contain it.

> Or do we need to bump something else?

If you change the ABI of, say, get_command() you
would need to bump the major version number for
libgfortran.

> And would that be fine, given that 14-development is in stage-3?
> Or rather wait for the next stage-1?

In the past gfortran developers have had some leeway in 
making this type of change in stage-3, because the change
would only affect gfortran (unless you somehow manage to
break bootstrap).  

For these changes, I think we need create new symbols.
I'm not a fan of encoding F2018 into the name as the 'new'
optional arguments are present in F2023.  Perhaps, a simple
version number _gfortran_get_command_v1_i4.

-- 
Steve

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

[Harald Anlauf]

Hi Steve,

> At one time, we kept track of things that would break
> libgfortran's ABI on the wiki.  You can find the list
> at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup.
> This could be old and moldy as I haven't checked in
> on ABI changes in a long time.

this looks indeed old and moldy...

> > 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.
> >
> > Do we have recommendations for a naming scheme?
> > Like _gfortran_F2018_get_command_i4
> > or _gfortran_get_command_F2018_i4, or better?
>
> The only convention that I can recall is the
> _gfortran_ prefix and the kind type suffix _i4.

OK.

> > And would that be fine, given that 14-development is in stage-3?
> > Or rather wait for the next stage-1?
>
> In the past gfortran developers have had some leeway in
> making this type of change in stage-3, because the change
> would only affect gfortran (unless you somehow manage to
> break bootstrap).

There's always this tiny chance to overlook something ...

> For these changes, I think we need create new symbols.
> I'm not a fan of encoding F2018 into the name as the 'new'
> optional arguments are present in F2023.  Perhaps, a simple
> version number _gfortran_get_command_v1_i4.

I also thought about the version number, but wasn't really happy
with it.  The new interface would exist for F2018+.  I am not
aware that any intrinsic ever lost an argument, and dealing
with that would be trivial.

The intrinsics mentioned are special in the sense that they
have a common additional optional argument ERRMSG, and they
are all impure subroutines.  This allows for another solution:
keeping the ERRMSG as a kind of "iostat" in the library,
and if this argument is present in the call, one can inquire
libgfortran to return that ERRMSG.  This would even be
backward-compatible. :-)

The biggest issue I see is that this library variable would
need to be thread-local.  I have to figure that out yet...

Harald