public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [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

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).