This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Andre Vehreschild <vehre at gmx dot de>
- Cc: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, jerry DeLisle <jvdelisle at charter dot net>, Damian Rouson <damian at sourceryinstitute dot org>, Ian Chivers <ian dot chivers at chiversandbryan dot co dot uk>, Jane Sleightholme <jane at fortranplus dot co dot uk>
- Date: Mon, 29 Aug 2016 11:46:56 +0300
- Subject: Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)
- Authentication-results: sourceware.org; auth=none
- References: <CAGkQGiKvbLD8azLWWaxMSSpSXWb_qHWFFA3=MwG8VFK+-mZ+wg@mail.gmail.com> <CAO9iq9GgiWfta1xDMGo4YT4jShHGKRV0BcfnkTdr42qz4Vvhmg@mail.gmail.com> <20160829101558.067e980c@vepi2>
On Mon, Aug 29, 2016 at 11:15 AM, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi all,
>
>> Anyway, a small nit I found was the function st_set_nml_var in
>> libgfortran. This is an exported function, and thus part of the ABI.
>> So you cannot add arguments to it, as that would break backwards
>> compatibility.
>
> Please explain the above. I was of the opinion, that when we change
> something significantly the global ABI version gets bumped. Given that
> we are doing gcc-7 currently and there have been some changes, that ABI
> version should have been bumped already with respect to gcc-6.
We strive very(?) hard to retain ABI compatibility for libgfortran, as
having to recompile everything is a huge PITA for our users. As a
result we have been able avoid bumping the SO major version number
since GCC 4.3 IIRC.
There is a long laundry-list of cleanups that could be done once we do
bump the SO major version:
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup
Probably when (if?) the new array descriptor is merged we have to do
said bump, as that one is used everywhere and retaining compatibility
with the old descriptor seems to be a huge undertaking.
> I am asking that stupid question mostly, because during extending
> coarray stuff to support allocatable components in derived typed
> coarrays the API of the caf-library has to be modified and carrying
> along the old signatures just causes useless garbage being carried
> forward. (Opencoarrays is working on supporting the same renovated API.
> Other users of that API are not known to me.) So what is the best way
> to resolve this?
I haven't involved myself in the coarray stuff, but AFAIU the corray
lib hasn't been considered stable, in order that the developers can
more quickly iterate on the design without having to be bogged down by
ABI compatibility considerations.
--
Janne Blomqvist