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
