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

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Mon, Aug 29, 2016 at 1:15 PM, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> 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 :-)

fnode and gfc_unit are private to libgfortran, so these can be changed
in any way you see fit.

st_parameter_dt, however, is more complex. It is allocated by the
frontend on the stack, with some empty space to be used as scratch
space by the library (the st_parameter_dt.u member). So you're free to
do whatever you want with the private part, as long as you keep the
size of the u.p struct smaller than u.pad (which should happen
automagically unless you have mangled check_st_parameter_dt somehow).
Otherwise I don't think you should go and touch st_parameter_dt.

This design is somewhat unfortunate, in that it quite severely
restricts the recursion depth of any function potentially doing I/O.
Say, you have a recursive function that writes something if some
condition is met. Any function potentially doing I/O bumps up the
stack by almost 1kB..  I'm thinking a simpler design for handling the
large number of optional I/O specifiers could be something like having
3 arguments, an array of keys, an array of values, and a scalar
telling how many elements the key/value arrays have. That way only the
specifiers that are actually specified would need to have space
allocated and be transferred. And then instead of a having the
frontend allocate a large scratch space on the stack, the library
could use a TLS variable to look it up.

But anyway, talk is cheap, and I'm unlikely to have time to implement
the above any time soon... :(


>
> 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



-- 
Janne Blomqvist