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
