This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/63640] move_alloc memory leak


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]