[Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

[Paul Richard Thomas]

Pushed to master as r11-6341-g0175d45d14b1f9ebc4c15ea5bafcda655c37fc35

I'll try to deal with the rest of the memory leaks over the next days.

Thanks

Paul

On Sat, 26 Dec 2020 at 09:04, Paul Richard Thomas <
paul.richard.thomas@gmail.com> wrote:

> Hi Thomas,
>
> Thanks for the review. You'll find answers to the questions below:
>
> On Fri, 25 Dec 2020 at 11:04, Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> First of all, merry Christmas everybody!
>>
>> Regarding the patch:
>>
>> > Regtests on FC33/x86_64 and the testcase is fixed with -m32. OK for
>> master?
>>
>> It's OK by me.
>>
>> There is just one piece of code that I don't understand:
>> ....snip....
>>
>
>
>> Could you maybe (for my personal education, and that of others who read
>> this code) add a comment what "lss = gfc_ss_terminator" tests, and why
>> it that one or the other post block is selected for adding the
>> deallocation?  I simply don't know what this idiom means.
>>
>
>  lss == gfc_ss_terminator tells us that the lhs is a scalar and so the
> scalarizer will not have generated a loop. Placing the deallocation of
> allocatable components inside a scalarizer loop will generally cause
> unintended outcomes :-)
>
> Look at the end of the section "Using pre-generated expressions" in
> https://gcc.gnu.org/wiki/GFortranScalarizer
>
> Regards
>
> Paul
>
>


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