Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Hi Janne, Andre, Jerry and All,

I am perfectly happy to adopt Janne's suggestion for
st_set_(dtio_)nml_var. Do the changes to the IO structures have any
impact? These are in:

fnode, st_parameter_dt & gfc_unit

I don't think that these should be visible but I want expert opinion
before making that assumption :-)

Cheers


Paul

On 29 August 2016 at 10:46, Janne Blomqvist <blomqvist.janne@gmail.com> wrote:
> 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



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein