Ping! [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Ping! [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

[Paul Richard Thomas]

Hi Jerry,

I apologise for the long delay in replying to you. I was on vacation
in a location that excluded all but the most meagre emails :-) In
addition, my workstation has been in the repair shop for the last
couple of weeks and is now the subject of a warranty claim.

The span field is added in the middle of the descriptor because the
caf token field makes the descriptor variable length. This is
reflected in the change in libgfortran.h.

It has crossed my mind that I should add some more fields, by
expanding the dtype field, which would then allow us to bump up the
maximum number of dimensions for example.

I have also fixed the ASSOCIATE problem that was reported in the
thread on clf that Thomas started.

However, I would appreciate somebody reviewing what I already posted.
Damian has had problems applying the patch. I suggest that the -l
option be applied, since my editor fixes whitespace problems on the
fly.

Best regards

Paul


On 11 July 2017 at 15:48, Jerry DeLisle <jvdelisle@charter.net> wrote:
> On 07/11/2017 07:23 AM, Paul Richard Thomas wrote:
>> Well, a bit earlier than anticipated, here is the final version that
>> puts right all the wrinkles that I know about.
>>
>> Bootstraps and regtests - OK for trunk?
>>
>> Paul
>
> Somewhere in the threads on this, there was mentioned ABI breakage/change.
>
> Does it really do this? If the significant change is in the descriptor and you
> just added the span on the end of the structure, I am not convinced this is an
> issue. (I have not studied the patch at all, I would rather not bump library
> version)
>
> Jerry



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: Ping! [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

[Paul Richard Thomas]

Dear Thomas,

Committed as revision 251949.

Thanks for both the review and the advice on the library version number.

Cheers

Paul

On 10 September 2017 at 15:39, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Hi Paul,
>
>> Excuse my ignorance - how do we bump up the library version? Is this
>> the number that appears in libtool-version? If so, which of the
>> numbers do I bump?
>
>
> You bump the first one - this then has to be
>
> 4:0:0
>
> Revision 241497 was the last time this was done.
>
>> In addition to the other changes that you mention, I have a mind to
>> add a few extra fields to the array descriptor: Split up dtype into
>> three fields, so that the maximum rank can increase to 15 and the
>> extended number of types can be accommodated; add a field for status
>> flags; and a field reserved to point to the vtable.
>
>
> All of these look very good.
>
>> This latter would
>> allow us to roll class objects into the array descriptor as Tobias
>> frequently proposed. It does cross my mind that another field could
>> point to a TR 29113 descriptor, even if we didn't use it internally.
>>
>> I intend to commit the patch for PR34640 as is, so that no further bit
>> rot develops. This implies a two stage bumping of the library version
>> number.
>
>
> Well, gcc-8 is a development version.  We only need to bump the library
> version once for each gcc-8. So, yes, please commit, and we should make
> sure to make to cram as many potentially incompatible (but reasonable
> :-) changes into this release as possible.
>
> Regards
>
>         Thomas



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein