* [Patch, fortran] PR104272 - finalizer gets called during allocate
@ 2023-04-05 6:53 Paul Richard Thomas
2023-04-05 18:50 ` Harald Anlauf
0 siblings, 1 reply; 5+ messages in thread
From: Paul Richard Thomas @ 2023-04-05 6:53 UTC (permalink / raw)
To: fortran, gcc-patches
[-- Attachment #1.1: Type: text/plain, Size: 1272 bytes --]
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.
OK for mainline?
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
[-- Attachment #2: pr104272.diff --]
[-- Type: application/x-patch, Size: 3031 bytes --]
[-- Attachment #3: finalize_52.f90 --]
[-- Type: text/x-fortran, Size: 1415 bytes --]
! { dg-do run }
!
! Test the fix for PR104272 in which allocate caused an unwanted finalization
!
! Contributed by Kai Germaschewski <kai.germaschewski@gmail.com>
!
module solver_m
implicit none
type, abstract, public :: solver_base_t
end type solver_base_t
type, public, extends(solver_base_t) :: solver_gpu_t
complex, dimension(:), allocatable :: x
contains
final :: solver_gpu_final
end type solver_gpu_t
type, public, extends(solver_gpu_t) :: solver_sparse_gpu_t
contains
final :: solver_sparse_gpu_final
end type solver_sparse_gpu_t
integer :: final_counts = 0
contains
impure elemental subroutine solver_gpu_final(this)
type(solver_gpu_t), intent(INOUT) :: this
final_counts = final_counts + 1
end subroutine solver_gpu_final
impure elemental subroutine solver_sparse_gpu_final(this)
type(solver_sparse_gpu_t), intent(INOUT) :: this
final_counts = final_counts + 10
end subroutine solver_sparse_gpu_final
end module solver_m
subroutine test
use solver_m
implicit none
class(solver_base_t), dimension(:), allocatable :: solver
allocate(solver_sparse_gpu_t :: solver(2))
if (final_counts .ne. 0) stop 1
end subroutine
program main
use solver_m
implicit none
call test
if (final_counts .ne. 22) stop 2 ! Scalar finalizers for rank 1/size 2
end program
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Patch, fortran] PR104272 - finalizer gets called during allocate
2023-04-05 6:53 [Patch, fortran] PR104272 - finalizer gets called during allocate Paul Richard Thomas
@ 2023-04-05 18:50 ` Harald Anlauf
2023-04-05 18:53 ` Harald Anlauf
2023-04-05 20:33 ` Paul Richard Thomas
0 siblings, 2 replies; 5+ messages in thread
From: Harald Anlauf @ 2023-04-05 18:50 UTC (permalink / raw)
To: Paul Richard Thomas, fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Patch, fortran] PR104272 - finalizer gets called during allocate
2023-04-05 18:50 ` Harald Anlauf
@ 2023-04-05 18:53 ` Harald Anlauf
2023-04-05 18:53 ` Harald Anlauf
2023-04-05 20:33 ` Paul Richard Thomas
1 sibling, 1 reply; 5+ messages in thread
From: Harald Anlauf @ 2023-04-05 18:53 UTC (permalink / raw)
To: Paul Richard Thomas, fortran, gcc-patches
On 4/5/23 20:50, Harald Anlauf via Gcc-patches wrote:
> 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).
Oops, I meant 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Patch, fortran] PR104272 - finalizer gets called during allocate
2023-04-05 18:53 ` Harald Anlauf
@ 2023-04-05 18:53 ` Harald Anlauf
0 siblings, 0 replies; 5+ messages in thread
From: Harald Anlauf @ 2023-04-05 18:53 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
On 4/5/23 20:50, Harald Anlauf via Gcc-patches wrote:
> 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).
Oops, I meant 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Patch, fortran] PR104272 - finalizer gets called during allocate
2023-04-05 18:50 ` Harald Anlauf
2023-04-05 18:53 ` Harald Anlauf
@ 2023-04-05 20:33 ` Paul Richard Thomas
1 sibling, 0 replies; 5+ messages in thread
From: Paul Richard Thomas @ 2023-04-05 20:33 UTC (permalink / raw)
To: Harald Anlauf; +Cc: fortran, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]
Hi Harald,
Quite right - good spot. There was an 'else' that turned out to be
unnecessary.
Thanks
Paul
On Wed, 5 Apr 2023 at 19:50, Harald Anlauf <anlauf@gmx.de> wrote:
> 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
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-04-05 20:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-05 6:53 [Patch, fortran] PR104272 - finalizer gets called during allocate Paul Richard Thomas
2023-04-05 18:50 ` Harald Anlauf
2023-04-05 18:53 ` Harald Anlauf
2023-04-05 18:53 ` Harald Anlauf
2023-04-05 20:33 ` Paul Richard Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).