https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637
--- Comment #1 from Antony Lewis <antony at cosmologist dot info> ---
Here's a code that reproduces a similar issue without explicit final.
module MiscUtils
implicit none
contains
logical function isFloat0(R)
class(*), intent(in) :: R
select type(R)
type is (real)
isFloat0 = .true.
end select
end function isFloat0
end module MiscUtils
module results3
implicit none
public
Type ClTransferData2
real, dimension(:,:,:), allocatable :: Delta_p_l_k
end type ClTransferData2
type TCLdata2
Type(ClTransferData2) :: CTransScal, CTransTens, CTransVec
end type TCLdata2
type :: CAMBdata2
Type(TClData2) :: CLdata2
end type
end module results3
program driver
use results3
integer i
do i=1, 2
call test()
end do
contains
subroutine test
implicit none
class(CAMBdata2), pointer :: Data
allocate(CAMBdata2::Data)
allocate(Data%ClData2%CTransScal%Delta_p_l_k(3, 1000, 1000))
allocate(Data%ClData2%CTransVec%Delta_p_l_k(3, 1000, 1000))
deallocate(Data)
end subroutine test
end program driver
docker run --rm -v "$(pwd):/workspace" -w /workspace
cmbant/docker-gcc-build:devel bash -c "
echo 'Building CAMB...' && gfortran -v &&
gfortran camb_memory_leak_test_nofinal.f90 && valgrind ./a.out"
Building CAMB...
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --build=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250611 (experimental) (GCC)
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1== Command: ./a.out
==1==
==1==
==1== HEAP SUMMARY:
==1== in use at exit: 24,000,000 bytes in 2 blocks
==1== total heap usage: 27 allocs, 25 frees, 48,006,134 bytes allocated
==1==
==1== LEAK SUMMARY:
==1== definitely lost: 0 bytes in 0 blocks
==1== indirectly lost: 0 bytes in 0 blocks
==1== possibly lost: 24,000,000 bytes in 2 blocks
==1== still reachable: 0 bytes in 0 blocks
==1== suppressed: 0 bytes in 0 blocks
==1== Rerun with --leak-check=full to see details of leaked memory
On ubuntu with gcc 13.1 I get similar but half "definitely lost".
