https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-12-15
--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
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
