Re: [Patch, fortran] PR104272 - finalizer gets called during allocate

[Harald Anlauf <anlauf@gmx.de>]

Hi Paul,

On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote:
> Hi All,
> 
> This is a first in my recent experience - a very old bug that produces too
> many finalizations! It results from a bit of a fix up, where class objects
> are allocated using the derived typespec, rather than a source or mold
> expression. This occurs upstream in resolve.cc, where the default
> initializer is assigned to expr3 but no means are provided to identify what
> it is. The patch applies a signaling bit-field to the ext field of
> gfc_code, which then suppresses the deallocation of allocatable components
> in the allocate expression. I have checked that this does not cause memory
> leaks, even though the number of builtin_frees in class_result_8.f90 goes
> down by one.

can you have a look again at the logic in the hunk touching
trans-stmt.cc (gfc_trans_allocate)?  I haven't checked in detail,
but it seems possible that you get a stale tmp in the
gfc_prepend_expr_to_block if (code->ext.alloc.expr3_not_explicit == 0).
Wouldn't it make more sense to move this condition before the braces
as part of the overall condition?

> OK for mainline?

Otherwise this LGTM.

Thanks for the patch!

Harald

> Paul
> 
> Fortran: Fix and excess finalization during allocation [PR104272]
> 
> 2023-04-04  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