[Bug fortran/110626] [13/14/15 regression] Duplicated finalization in derived

2025-04-14 Thread abensonca at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626

--- Comment #5 from Andrew Benson  ---
Thanks Paul. I'm always happy to be patient - I appreciate the huge amount of
work you put in to gfortran (and the many different priorities within that
work).

[Bug fortran/110626] [13/14/15 regression] Duplicated finalization in derived

2025-04-14 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626

--- Comment #4 from Paul Thomas  ---
(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

[Bug fortran/110626] [13/14/15 regression] Duplicated finalization in derived

2025-02-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/110626] [13/14/15 regression] Duplicated finalization in derived

2024-12-15 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626

Paul Thomas  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  ---
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

[Bug fortran/110626] [13/14/15 regression] Duplicated finalization in derived

2024-11-28 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
Summary|Duplicated finalization in  |[13/14/15 regression]
   |derived |Duplicated finalization in
   ||derived
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105170
   Keywords||wrong-code