Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

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

Hi Thomas,

It will break binary compatibility for caf with scalar,
allocatable/pointer components. This comes about because I decided
that the caf tokens for thes components, should come after all other
components, rather than immediately after the "owner" component. This
has the advantage, that they are then binary compatible with external
functions or modules that are not compiled with -fcoarray = lib.

Arrays will continue to be binary compatible.

Thanks

Paul


On 27 December 2017 at 16:09, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Hi Paul,
>
>> This is a complete rework of the patch and of the original mechanism
>> for adding caf token fields and finding them.
>>
>> In this patch, the token fields are added to the derived types after
>> all the components have been resolved. This is done so that all the
>> tokens appear at the very end of the derived type, including the
>> hidden string lengths. This avoids the present situation, where the
>> token appears immediately after its associated component such that the
>> the derived types are not compatible with modules or libraries
>> compiled without -fcoarray selected. All trans-types has to do now is
>> to find the component and have the component token field point to its
>> backend_decl. PR83319 is fixed by unconditionally adding the token
>> field to the descriptor, when -fcoarray=lib whatever the value of
>> codimen.
>
>
> This looks very good.
>
> I just have one question: Will this break binary compatibility for
> the 7-branch? Or will this only break compatibility for something
> that never worked anyway?
>
> Regards
>
>         Thomas
>



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