Re: [patch, fortran] Fix pointers not escaping via C_PTR

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

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