https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412
--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Tue, Jun 07, 2016 at 02:40:18AM +0000, relliott at umn dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 > > --- Comment #9 from relliott at umn dot edu --- > I still believe there is a bug associated with the iso_c_bindings > and c_loc() support. In the attached, I've created an example > program that shows that ALLOCATABLE local variables are deallocated > at the end of a routine (noleak), but pointer variables are not (leak). > > Then, I've created a program without using iso_c_bindings that gives > the same result for -O0 and -O3 (pointer_fortran) and a program that > uses iso_c_bindings to do the same thing that gives different results > for -O0 and -O3 (pointer_cstyle). > > Use the 'runme.sh' script to illustrate the following behavior: > I don't do bash, so runme.sh is useless. I believe that at least some of your codes leak memory, but this is your fault not gfortran's fault. From F2003: If an unsaved allocatable object is a local variable of a module, and it is allocated when execution of a RETURN or END statement results in no active scoping unit having access to the module, it is processor-dependent whether the object retains its allocation status or is deallocated. Perhaps, you wanted to write: subroutine store(a) use pointerstore, only : p implicit none real, pointer, intent(in) :: a if (associated(p)) deallocate(p) p => a return end subroutine store Then there are these jewels from 16.5.6 (14) When the association status of a pointer becomes undefined or disassociated (16.4.2.1.2-16.4.2.1.3), the pointer becomes undefined. (17) When execution of a RETURN or END statement causes a variable to become undefined, any variable of type C_PTR becomes undefined if its value is the C address of any part of the variable that becomes undefined. (18) When a variable with the TARGET attribute is deallocated, any variable of type C_PTR becomes undefined if its value is the C address of any part of the variable that is deallocated. gcc bugzilla is a not Fortran teaching forum. Please take your examples to comp.lang.fortran. There are a number of experts (include current and former members of the Fortran standardization committee) that answer questions there. In fact, the former technical editor of both Fortran 95 and 2003 is quite active there. He often warns people to avoid using pointers. If you can get any of those experts to agree with your assertion that a bug exists, then be all means come back and report a simple self-contained example.
