https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128357
--- Comment #3 from Steve Kargl <kargl at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #2)
> I do understand about the OS job to reclaim memory. I need to think about it
> as well
program foo
integer, allocatable :: i(:)
allocate(i(3))
i = [1, 2, 3]
if (sum(i) /= 6) stop 1
end program
%gfcx -o z d.f90
% valgrind ./z
==94629==
==94629== HEAP SUMMARY:
==94629== in use at exit: 12 bytes in 1 blocks
==94629== total heap usage: 19 allocs, 18 frees, 6,608 bytes allocated
==94629==
==94629== LEAK SUMMARY:
==94629== definitely lost: 12 bytes in 1 blocks
==94629== indirectly lost: 0 bytes in 0 blocks
==94629== possibly lost: 0 bytes in 0 blocks
==94629== still reachable: 0 bytes in 0 blocks
==94629== suppressed: 0 bytes in 0 blocks
When the process 'z' completes, the OS will reap the process
and reclaim allocated memory. There is no memory leak. The
Fortran standard does require a 'deallocate(i)' before the
'end program' statement. (To me,) the above valgrind output
appears to a false positive in the leak summary.
So, in your example code, you have 'call sq ((q), zs)'. The
temporary variable lives in the namespace of the main program.
When the program ends, there is no leak in that the Fortran
standard does require one to clean up allocated memory. Now,
if you had
block
call bar(q, zs)
end block
when bar returns any memory allocated in the block's namespace
should be cleaned up.
In short, it comes down to the pseudocode
allocate(tmp)
tmp = (qs)
call bar(tmp, zs)
deallocate(tmp)
PS:
This does what I expected as the allocate() is within
the namespace of block.
program foo
block
integer, allocatable :: i(:)
allocate(i(3))
i = [1, 2, 3]
if (sum(i) /= 6) stop 1
end block
end program
% valgrind ./z
==94706==
==94706== HEAP SUMMARY:
==94706== in use at exit: 0 bytes in 0 blocks
==94706== total heap usage: 19 allocs, 19 frees, 6,608 bytes allocated
