[Bug fortran/104272] New: finalizer gets called during allocate

[Bug fortran/104272] New: finalizer gets called during allocate

[kai.germaschewski at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

            Bug ID: 104272
           Summary: finalizer gets called during allocate
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kai.germaschewski at gmail dot com
  Target Milestone: ---

Created attachment 52310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52310&action=edit
reproducer

This issue appears to be present in gfortran-9,10,11. A minimal reproducer is
provided.

I have an abstract base class, from which one class is derived which itself is
further derived one more time. When allocating an array of the most-derived
type, for some reason the finalizer of the intermediate class is called. This
does not happen with ifort or xlf, and I don't think it should happen.

output:

 allocating
 solver_gpu_final    <-- this being called is a bug (IMHO)
 allocating done
 solver_sparse_gpu_final
 solver_sparse_gpu_final
 solver_gpu_final
 solver_gpu_final

[Bug fortran/104272] finalizer gets called during allocate

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
This is still the case after Paul's big finalization update.
Adding him in CC.

@Paul: can you comment?

[Bug fortran/104272] finalizer gets called during allocate

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org
   Last reconfirmed|                            |2023-04-03
     Ever confirmed|0                           |1

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Kai,

Thanks for the report.

nagfor agrees that the finalization shouldn't occur. From the work that I did
on finalization, nagfor was the most compliant of all the compilers that I have
access to.

I am currently working on ASSOCIATE bugs but will come back to tidy up some of
the finalization nits in a few weeks time.

Confirming and taking the bug.

Cheers

Paul

[Bug fortran/104272] finalizer gets called during allocate

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Following the allocation itself, we get:
        solver._data.dim[0].lbound = 1;
        solver._data.dim[0].ubound = 2;
        solver._data.dim[0].stride = 1;
        solver._data.offset = -1;
        solver._data.span = 64;
        {
          integer(kind=8) D.4532;
          integer(kind=8) D.4533;
          integer(kind=8) D.4534;
          struct solver_sparse_gpu_t * D.4535;

          D.4532 = solver._data.offset;
          D.4533 = solver._data.dim[0].lbound;
          D.4534 = solver._data.dim[0].ubound;
          D.4535 = &source.16;
          {
            integer(kind=8) S.20;

            S.20 = D.4533;
            while (1)
              {
                if (S.20 > D.4534) goto L.28;
                {
                  struct __vtype_solver_m_Solver_base_t * {ref-all} D.4537;

                  solver._vptr = (struct __vtype_solver_m_Solver_base_t *
{ref-all}) &__vtab_solver_m_Solver_sparse_gpu_t;
                  D.4537 = solver._vptr;
                  solver._vptr->_copy (D.4535, (struct solver_base_t *)
solver._data.data + (sizetype) ((S.20 + D.4532) * solver._vptr->_size));
                }
                S.20 = S.20 + 1;
              }
            L.28:;
          }
        }
        desc.17.dtype = {.elem_len=64, .rank=0, .type=5};
        desc.17.data = (void * restrict) &source.16.solver_gpu_t;
        desc.17.span = (integer(kind=8)) desc.17.dtype.elem_len;
        __final_solver_m_Solver_gpu_t (&desc.17, 64, 1);
        if ((complex(kind=4)[0:] * restrict) source.16.solver_gpu_t.x.data !=
0B)
          {
            __builtin_free ((void *) source.16.solver_gpu_t.x.data);
            (complex(kind=4)[0:] * restrict) source.16.solver_gpu_t.x.data =
0B;
          }

So there it is, writ large at the end. For some reason, gfc_trans_allocate
applies a default initializer and the finalizes and nulls the component.

Paul

[Bug fortran/104272] finalizer gets called during allocate

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 54811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54811&action=edit
Fix for this PR

I was sufficiently intrigued by this bug that I decided that I would look into
it right away. After all, it is the first time that such an old finalization
problem was producing too many calls to the final subroutine.

I'll be posting to the list after checking the deja-gnuified testcase.

Paul

[Bug fortran/104272] finalizer gets called during allocate

[kai.germaschewski at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

--- Comment #5 from Kai Germaschewski <kai.germaschewski at gmail dot com> ---
(In reply to Paul Thomas from comment #4)
> Created attachment 54811 [details]
> Fix for this PR
> 
> I was sufficiently intrigued by this bug that I decided that I would look
> into it right away. After all, it is the first time that such an old
> finalization problem was producing too many calls to the final subroutine.
> 
> I'll be posting to the list after checking the deja-gnuified testcase.
> 
> Paul

Thanks a lot for looking into this. I briefly looked at `gfc_trans_allocate`,
but it's definitely beyond me ;)

[Bug fortran/104272] finalizer gets called during allocate

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:b0e85485fbf042abccee5c0a9eb499da386c8db3

commit r13-7181-gb0e85485fbf042abccee5c0a9eb499da386c8db3
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Fri Apr 14 11:14:00 2023 +0100

    Fortran: Fix an excess finalization during allocation [PR104272]

    2023-04-14  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/104272
            * gfortran.h : Add expr3_not_explicit bit field to gfc_code.
            * resolve.cc (resolve_allocate_expr): Set bit field when the
            default initializer is applied to expr3.
            * trans-stmt.cc (gfc_trans_allocate): If expr3_not_explicit is
            set, do not deallocate expr3.

    gcc/testsuite/
            PR fortran/104272
            * gfortran.dg/class_result_8.f90 : Number of builtin_frees down
            from 6 to 5 without memory leaks.
            * gfortran.dg/finalize_52.f90: New test

[Bug fortran/104272] finalizer gets called during allocate

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on mainline. I am closing it but will incorporate this in a composite
finalization patch for 12-branch.

Thanks for the report

Paul