[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > (In reply to Thomas Koenig from comment #2) > > Is this actually required? My feeling would be that is is not, but I may > > well be mistaken. > > > > Does somebody have chapter & verse on this? And what do other compilers do? > > NAG, Intel & Cray do not leak according to valgrind. NAG also gives a nice > runtime memory trace with -mtrace. > > I think the following applies: > > F2018 DIS: > > 9.7.3.2 Deallocation of allocatable variables > > 8 When a variable of derived type is deallocated, any allocated allocatable > subobject is deallocated. [...] > > I do not see any mentioning to whether "variable" is ALLOCATABLE or POINTER > here. You don't need to see ALLOCATABLE or POINTER. In "..., any allocated allocatable ...' the word 'allocatable' has an internal link to its definition. 3.2 allocatable having the ALLOCATABLE attribute (8.5.3) 8.5.3 ALLOCATABLE attribute A variable with the ALLOCATABLE attribute is a variable for which space is allocated during execution. Here, we see that 'allocatable' does not include 'POINTER attribute'. So, now, we go back to the beginning of the section The DEALLOCATE statement causes allocatable variables to be deallocated; it causes pointer targets to be deallocated and the pointers to be disassociated. For the lack of a better description, 'allocate(test(10))' allocates an anonymous target. 'deallocate(test)' deallocates that anonymous target and dissociates the pointer. So, now we go to 9.7.3.3 "Deallocation of pointer targets" This section does not say what happens to allocated allocatable components when the pointer target is deallocated. QoI probably means that gfortran should do a deep deallocation, but I don't think it is required by the Fortran standard.
[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 --- Comment #4 from c.s.brady at warwick dot ac.uk --- My belief was based on the same statement in section 6.3.3 of the F2003 standard
[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) > Is this actually required? My feeling would be that is is not, but I may > well be mistaken. > > Does somebody have chapter & verse on this? And what do other compilers do? NAG, Intel & Cray do not leak according to valgrind. NAG also gives a nice runtime memory trace with -mtrace. I think the following applies: F2018 DIS: 9.7.3.2 Deallocation of allocatable variables 8 When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated. [...] I do not see any mentioning to whether "variable" is ALLOCATABLE or POINTER here.
[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Is this actually required? My feeling would be that is is not, but I may well be mistaken. Does somebody have chapter & verse on this? And what do other compilers do?
[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-06 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. All tested versions since at least 4.3 show the leak.
