This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/63640] move_alloc memory leak
- From: "janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 23 Dec 2014 09:32:57 +0000
- Subject: [Bug fortran/63640] move_alloc memory leak
- Auto-submitted: auto-generated
- References: <bug-63640-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|WAITING |RESOLVED
CC| |janus at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Joost VandeVondele from comment #4)
> seems more like an enhancement request to free allocatables at the end of
> main. I guess this is not mandated by the standard
Right. The Fortran standard only requires the compiler to auto-deallocate
variables which live inside a function/subroutine, but not those declared
directly in the main program.
Nevertheless gfortran did it up to version 4.8. I verified that compiling with
4.8.3. does not show any memory leaks.
The auto-deallocation of variables in the main program was removed in 4.9,
because it can alter the run-time behavior with FINAL routines, so one should
better stick to the standard and *not* do it. It's the programmer's
responsibility to deallocate variables in the main program, and the easiest way
to get rid of the valgrind warnings is to do explicitly do this:
program testmv3
type bar
integer, allocatable :: ia(:), ja(:)
end type
integer, allocatable :: ia(:), ja(:)
type(bar), allocatable :: sm,sm2
allocate(sm)
allocate(sm2)
allocate(sm%ia(100),sm%ja(100))
allocate(sm2%ia(1000),sm2%ja(1000))
allocate(ia(100),ja(1000))
call move_alloc(ja,ia)
call move_alloc(sm%ia,sm2%ia)
call move_alloc(sm%ja,sm2%ja)
deallocate(ia,sm2%ia,sm2%ja)
deallocate(sm,sm2)
end program testmv3
This program does not show any leaks. The leaks you were seeing are definitely
not due to any problem with MOVE_ALLOC.