[Bug fortran/71412] iso_c_bindings and optimization interaction bug

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Jun 06, 2016 at 06:51:16PM +0000, relliott at umn dot edu wrote:
> 
> I just want to make one think certain.  You quoted section 6.3.3.1 of the 
> J3/04-007 document to show that a NAMED local allocatable variable would be 
> deallocated at the end of a routine.
> 
> However, it is unclear to me that this applies to a POINTER variable
> (as I have in my skeleton code).
> 
> In Section 6.3.1.2 is says:
> 
>     Allocation of a pointer creates an object that implicitly has the TARGET
>     attribute. Following successful execution of an ALLOCATE statement for a
>     pointer, the pointer is associated with the target and may be used to
>     reference or define the target

Finishing reading that paragraph:

   It is not an error to allocate a pointer that is already
   associated with a target. In this case, a new pointer
   target is created as required by the attributes of the
   pointer and any array bounds, type, and type parameters
   specified by the ALLOCATE statement.  The pointer is then
   associated with this new target.  Any previous association
   of the pointer with a target is broken.  If the previous
   target had been created by allocation, it becomes inaccessible
   unless other pointers are associated with it.

   integer(c_int), pointer, save :: val  ! Retain pointer associate with SAVE
   allocate(val)                         ! Allocate a new target object
   call store_ptr(index, c_loc(val))     ! Cache pointer for C code.

See more below. 

> This seems to say that an UNNAMED allocatable target object is created
> when the allocate statement for a pointer variable is executed.  In
> which case, section 6.3.3.1 is not applicable.
> 
> Can you help me to understand why this is not the case?
> 

6.3.3.1 still applies (see the highlighted phrase).

   When the execution of a procedure is terminated by execution of
   a RETURN or END statement, an allocatable variable that is a named
   local variable of the procedure retains its allocation
   **** and definition status ****
   if it has the SAVE attribute or is a function result variable or
   a subobject thereof; otherwise, it is deallocated.

You now need to chase down the meaning of definition status.

   16.4.2.1.3

   The association status of a pointer becomes undefined when
   ...
(4)  Execution of a RETURN or END statement causes the pointer's
     target to become undefined (item (3) of 16.5.6),
(5)  A procedure is terminated by execution of a RETURN or END
     statement and the pointer is declared or accessed in the
     subprogram that defines the procedure unless the pointer
        (a) Has the SAVE attribute,

   16.5.6

   Variables become undefined as follows:
   ...
(3)  When execution of an instance of a subprogram completes,
        (a) its unsaved local variables become undefined,