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

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

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