(j3.2006) a question on c_f_pointer call

[Bill Long]

Jim Xia wrote:
> 


>  > Jim Xia wrote:
>  > >
>  > > We're receiving a customer question on pointer's deallocation 
> status for
>  > > FPTR from intrinsic c_f_pointer().  Basically the question is whether
>  > > user should expect successful deallocation of FPTR from call
>  > > c_f_pointer.  This looks pretty much processor dependent since I can't
>  > > find clear wording in the standard specifying the behavior.  To be
>  > > specific, consider the following three cases
>  > >
>  > >
>  > > case 1
>  > >           use, intrinsic :: iso_c_binding
>  > >           implicit none
>  > >           integer stat
>  > >           type(c_ptr) :: cptr
>  > >           real(C_DOUBLE), pointer :: p, q
>  > >           allocate(p)
>  > >           cptr = c_loc(p)
>  > >           call c_f_pointer(cptr, q)
>  > >           deallocate(q, stat=stat)
>  > >           print *, stat
>  > >           end
>  > >
>  >
>  > This one looks OK.

For case 1, the question is whether the information that the target of q 
was created by allocation get lost when going through the route of a C 
pointer.   I got these results for stat:

Cray : 4412  (the information did, indeed, get lost - stat value is for 
pointer target not valid for deallocation)

Intel: 0

PGI : 0

gfortran : 0


>  >
>  > > case 2
>  > >           use, intrinsic :: iso_c_binding
>  > >           implicit none
>  > >           integer stat
>  > >           type(c_ptr) :: cptr
>  > >           real(C_DOUBLE), pointer :: p, q
>  > >           real(C_DOUBLE), target :: t
>  > >           p => t
>  > >           cptr = c_loc(p)
>  > >           call c_f_pointer(cptr, q)
>  > >           deallocate(q, stat=stat)
>  > >           print *, stat
>  > >           end
>  > >
>  >
>  > This is no legal. See 6.7.3.3 'Deallocation of pointer targets'.  In
>  > particular "Deallocating a pointer ... whose target was not created by
>  > an ALLOCATE statement causes an error condition in the DEALLOCATE
>  > statement".
>  >
For this case, where the standard explicitly requires an error condition:

Cray : 4412

Intel:  failure in glibc, "illegal pointer", with traceback, and the 
traceback hung (killed -9 from a different process)

PGI : 1

gfortran : same glibc failure as Intel, but did not hang.


>  >
>  > > case 3
>  > >           use, intrinsic :: iso_c_binding
>  > >           implicit none
>  > >           integer stat
>  > >           type(c_ptr) :: cptr
>  > >           real(C_DOUBLE), pointer :: p, q
>  > >           real(C_DOUBLE), target, allocatable :: t
>  > >           allocate (t)
>  > >           p => t
>  > >           cptr = c_loc(p)
>  > >           call c_f_pointer(cptr, q)
>  > >           deallocate(q, stat=stat)
>  > >           print *, stat
>  > >           end
>  > >
>  >
>  > Same section.  "If a pointer is associated with an allocatable entity,
>  > the pointer shall not be deallocated."
>  >

For this case, where the code is illegal, but the standard is less 
specific about issuing an error condition:

Cray : 4412

Intel : 0

PGI : 0

gfortran : failure in glibc, "double free or corruption", traceback (no 
hang).

>  > >
>  > > Note these tests are simplified with all pointers being entities
>  > > declared in main.  In practice these pointers could be dummy pointers
>  > > and the deallocations can happen in different scopes from the
>  > > c_f_pointer() function call.
>  > >
>  > > The question is: does standard require specific behavior on each of 
> the
>  > > DEALLOCATE statement?  I found the standard is vague in this.

The standard is evidently sufficiently vague to result in quite varied 
behavior.

What does the IBM compiler do?

Cheers,
Bill


-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101