> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran <fort...@gcc.gnu.org>
> wrote:
>
>
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
>> libgfortran ABI changed multiple times in the past already, e.g. the
>> so.1 -> so.2 transition in 4.2
>> so.2 -> so.3 transition in 4.3
>> so.3 -> so.4 transition in 7
>> so.4 -> so.5 transition in 8
>> and users have coped.
>
> Yes, and it has always been a hassle for users, and we've been
> criticized for it.
>
> This is currently a change which brings users on non-POWER-systems
> (the vast majority) all pain and no gain. If this cannot be
> avoided, I would at least try to fit in as much of other improvements
> as there are possible.
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangling depending on target).
.. perhaps I missed where that idea was already ruled out (in which case
sorry for the noise).
Iain
>
> There's a PR for it somewhere, but I can think of three areas, none
> of the small, and all require an ABI change:
>
> a) Get PDTs right (Paul?)
> b) Make file descriptors conform to the C interop version
> c) Remove the run-time parsing of I/O arguments and
> replace them with a bit field.
>
> What I mean by the last one is that
>
> WRITE (unit,'(A)',ADVANCE="NO")
>
> we currently parse the "NO" at runtime, for every statement
> execution. What we could be doing instead is to have
>
> dt_parm.0.advance = __gfortran_evaluate_yesno ("NO")
>
> where the latter function can be simplified at compile-time.
>
> We should strive to break the ABI as few times as possible.
>
> Best regards
>
> Thomas
