[Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Steve Kargl]

On Mon, Mar 10, 2014 at 04:46:50PM +0100, Janus Weil wrote:
> > Valgrind does not report "false positives" for other allocatable variables
> > in the main program.  Deferred length character variables should not be any
> > different.  In a main program they should all have the 'save' attribute as
> > required by the F2008 Standard.  So their allocations should persist through
> > the end of the program execution. Again, valgrind should be reporting "still
> > reachable", not "definitely lost".
> 
> It does in fact show "still reachable" on my system (x86_64-unknown-linux-gnu):
> 
> ==18219== LEAK SUMMARY:
> ==18219==    definitely lost: 0 bytes in 0 blocks
> ==18219==    indirectly lost: 0 bytes in 0 blocks
> ==18219==      possibly lost: 0 bytes in 0 blocks
> ==18219==    still reachable: 10 bytes in 1 blocks
> ==18219==         suppressed: 0 bytes in 0 blocks
> 
> That's also what happens with other allocatable variables in the main
> program which are not explicitly deallocated, and is exactly what
> should be expected. As shown, my valgrind version in 3.8.1, which is
> slightly newer than your 3.7.0.
> 

It may also depend on the underlying memory allocator.  I have
3.8.1 on FreeBSD, and valgrind reports "definitely lost".  IIRC,
valgrind was developed on linux, so it may be leveraging some
internal state of the allocator to categorize the leak.  For 
program termination, whether it is reported as "definitely lost"
or "still reachable" in the specific case of Walt's code is
immaterial as memory is returned to the OS.  Now, if the automatic
deallocation on exiting a subprogram was leaking, then we'd have
reason to be concerned. 

-- 
Steve