https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626
--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #3)
> Hello Javier,
>
> For some reason this bug slipped by me. I do apologise.
>
> I can confirm that there is a bug, which comes about from the use of a
> temporary for the defined assignment of the component. That of itself
> wouldn't matter, if the temporary were assigned to at the right time. This
> what the intermediate code looks like:
> o1.inner.val = 15;
> _F.DA0 = o2; // Assignment temporary here
> {
> struct array00_b desc.15;
>
> desc.15.dtype = {.elem_len=4, .version=0, .rank=0, .type=5};
> desc.15.data = (void * restrict) &o2;
> desc.15.span = (integer(kind=8)) desc.15.dtype.elem_len;
> __final_testmod_B (&desc.15, 4, 0); // 'o2' finalized before
> assignment
> }
> o2 = o1; // assignment of 'o1' to 'o2'
> { // temporary assign should be
> here
> struct __class_testmod_A_t class.16;
>
> class.16._vptr = (struct __vtype_testmod_A * {ref-all})
> &__vtab_testmod_A;
> class.16._data = &_F.DA0.inner;
> copy (&class.16, &o1.inner); // defined assignment of
> 'o1%inner'
> } // generates second
> finallization.
> o2.inner = _F.DA0.inner; // set the resulting 'o2%inner'
>
> For (pre-)historical reasons the assignment is not being done as required by
> the standard, ie. component by component, but, instead, only does the does
> the defined assignments by component.
>
> I will think about this.
>
> Paul
Hi Andrew,
I see that you have joined Javier in waiting for this one :-)
Strictly speaking this is not a regression since it is built into the defined
assignment of components from the very beginning. However, its being marked as
a regression helps me keep it in mind.
I can see two ways of fixing this, both of which involve a major amount of
work. My attack on PDTs is long overdue and so I must do that first. Please be
patient.
Regards
Paul
