On Thu, Feb 28, 2019 at 09:14:48PM +0100, Thomas Koenig wrote: > > the attached patch fixes a wrong-code bug for gfortran where pointers > were not marked as escaping. A C_PTR can be stashed away and reused > later (at least as long as the variable it points to remains active). > > This is not a regression, but IMHO a bad wrong-code bug. The chances > of this patch introducing regressions are really, really low. > > Regression-tested. OK for trunk? >
Is this a wrong code bug or a clever user wandering off into undefined behavior? > subroutine init() > use, intrinsic :: iso_c_binding > implicit none > integer(c_int), pointer :: a > allocate(a) > call save_cptr(c_loc(a)) > a = 100 > end subroutine init Of particular note, 'a' is an unsaved local variable. When init() returns, 'a' goes out-of-scope. Fortran normally deallocates an unsaved allocatable entity, but 'a' is an unsaved local variable with the pointer attribute. For lack of a better term, 'allocate(a)' allocates an anonymous target and associates the anonymous target with the pointer 'a'. save_ptr() caches the address of the anonymous target. When init() returns does the anonymous target get deallocated or does the program leak memory? In addition, when init() returns, what happens to the pointer association of 'a'? I think it becomes undefined, which means the anonymous memory is inaccessible at least by Fortran means as there are no pointers associated with the anonymous target. The Fortran standard does not what happens to leaked memory. In particular, the Fortran standard does not guarantee that leaked memory is not reaped by some garbage collection or that it must retain value 100. -- Steve
