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

[Janus Weil]

> 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== Memcheck, a memory error detector
==18219== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==18219== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==18219== Command: ./a.out
==18219==
 first string
 second string
 3rd string
==18219==
==18219== HEAP SUMMARY:
==18219==     in use at exit: 10 bytes in 1 blocks
==18219==   total heap usage: 24 allocs, 23 frees, 11,842 bytes allocated
==18219==
==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
==18219== Rerun with --leak-check=full to see details of leaked memory
==18219==
==18219== For counts of detected and suppressed errors, rerun with: -v
==18219== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)


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.

Cheers,
Janus




> On 03/09/2014 02:20 PM, Steve Kargl wrote:
>>
>> On Sun, Mar 09, 2014 at 11:48:04AM -0700, Walter Spector wrote:
>>>
>>> Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
>>>>
>>>> ...
>>>>      deallocate(string)  ! Fix valgrind
>>>
>>>
>>> I would agree in the case where 'string' had the pointer attribute.
>>> But with allocatables, valgrind should be seeing the memory block
>>> as 'still reachable'.
>>>
>>
>> Well, the string is still reachable at the end of the main
>> program, because the programmer has not deallocated the
>> memory.  Janus pointed to the PR where the behavior you are
>> seeing is discussed.  I don't recall all the details, but
>> as the program is terminating and all(most?) operating systems
>> return allocated memory to the OS, valgrind is essentially
>> reporting a false positive.
>>
>