The following gives valgrind error when the deallocate is commented out: program test integer, allocatable, dimension(:) :: VLQ integer i, filo allocate(VLQ(0)) do i=1, 5 filo = 2**i + 27 VLQ = [ VLQ, int(filo) ] print *, VLQ end do !deallocate(VLQ) end program ==16247== HEAP SUMMARY: ==16247== in use at exit: 20 bytes in 1 blocks ==16247== total heap usage: 38 allocs, 37 frees, 5,645 bytes allocated ==16247== ==16247== LEAK SUMMARY: ==16247== definitely lost: 20 bytes in 1 blocks
Yep. Valgrind giving a warning here is questionable. Is there an operating system, where gfortran works, that does not reap resources committed to a terminating process? In other words, not a gfortran problem.
Well I do not know about how all the hooks work but this is with the following configure: ../trunk/configure --prefix=/home/jerry/dev/usr --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap --enable-valgrind-annotations Enabling the valgrind annotations should give fairly accurate results. I do not know what you get on FreeBSD OS. I was using Fedora 40 OS.
The code you posted is standard conforming, and when compiled, executes as expected. My point is that the program is exiting. The operate system will reap the process and reclaim the memory. Valgrind need not warn about this. It is just noise. It is not a memory leak. If anything it is poor programming on the part of the person that wrote the code, and arguably a bug the code. If the valgrind nonsense bothers a programmer, then the programmer can do the explicit deallocation. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 > > --- Comment #2 from Jerry DeLisle <jvdelisle2 at gmail dot com> --- > Well I do not know about how all the hooks work but this is with the following > configure: > > ../trunk/configure --prefix=/home/jerry/dev/usr > --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap > --enable-valgrind-annotations > > Enabling the valgrind annotations should give fairly accurate results. I do not > know what you get on FreeBSD OS. I was using Fedora 40 OS. >
(In reply to kargls from comment #3) > The code you posted is standard conforming, and when > compiled, executes as expected. > > My point is that the program is exiting. The operate system will > reap the process and reclaim the memory. Valgrind need not warn > about this. It is just noise. It is not a memory leak. If anything > it is poor programming on the part of the person that wrote the > code, and arguably a bug the code. > I agree completely, I would prefer that programmers explicitly deallocate. I simply do not know what our expectations should be when testing. Maybe in this case it is a don't care. I posted the question for clarification from others.
(In reply to Jerry DeLisle from comment #4) > (In reply to kargls from comment #3) > > The code you posted is standard conforming, and when > > compiled, executes as expected. > > > > My point is that the program is exiting. The operate system will > > reap the process and reclaim the memory. Valgrind need not warn > > about this. It is just noise. It is not a memory leak. If anything > > it is poor programming on the part of the person that wrote the > > code, and arguably a bug the code. > > > > I agree completely, I would prefer that programmers explicitly deallocate. That's what I do in runtime tests (unless I forget to). > I simply do not know what our expectations should be when testing. Maybe in > this case it is a don't care. I posted the question for clarification from > others. Running the program from comment#0 - compiled with ifx - under valgrind gives here: ==12826== HEAP SUMMARY: ==12826== in use at exit: 60 bytes in 1 blocks ==12826== total heap usage: 13 allocs, 12 frees, 12,926 bytes allocated ==12826== ==12826== LEAK SUMMARY: ==12826== definitely lost: 0 bytes in 0 blocks ==12826== indirectly lost: 0 bytes in 0 blocks ==12826== possibly lost: 60 bytes in 1 blocks But as Steve pointed out: this is irrelevant, just a hint to the programmer.
This is similar to PR58433 (except there is no final procedure here).
Thankyou for comments. I will close as not a bug.