Re: Rules for valid pointer deallocation


*** Hendrickson wrote:

robert.corbett@xxxxxxx wrote:

I'm not sure about that. The requirement is also that the
pointer be associated with "the whole of an object..."
(page 116, line 25). Here, you pointer isn't
associated with the whole array, it's associated with
the array section array_ref(1:n). Try changing the
declaration in the function to
integer, target :: array_ref(:)
and see if anything better happens.


The program is not a standard-conforming program,
but not because of the size. Note that the extent of
the allocated array is 10 and the extent of the target
dummy array is also 10, because n is 10 in this
example.

Yes, but I still don't think size matters here. If
A is a 1D array, then A(lbound(a,1):ubound(a:1)) is
an array section, not the whole array.

The Fortran standard does not say that the whole array
must be specified in the DEALLOCATE statement.
Section 6.3.3.2 of the Fortran 95 standard states

A pointer that is not currently associated with the
whole of an allocated target object shall not be
deallocated. If a pointer is currently associated
with a portion (2.4.3.1) of a target object that is
independent of any other portion of the target
object, it shall not be deallocated.

Thus, the code fragment

POINTER P(:), Q{:}
ALLOCATE(P(100))
Q => P(:)
DEALLOCATE(Q)

is standard-conforming. There is no portion of the
array associated with P that is not also associated
with Q.

A horrid example is the code fragment

POINTER P(:), Q
ALLOCATE(P(1))
Q => P(1)
DEALLOCATE(Q)

This example is also standard-conforming. I believe
that almost anyone who saw and understood this
example would think it should not be allowed by the
standard. Nonetheless, whenever the question was
raised on the J3 mailing list, the answer consistently
was that it is standard-conforming. I will further
point out that a test suite Sun purchased from a
company that has a representative on J3 contains
multiple tests that would fail if code similar to this
example did not compile and run successfully.

In the second case, where the dummy is an explicit shaped
array--that's what is happening in the example-- it is
processor dependent whether or not pointers associated
with the dummy remain associated. So, the compilers
can go either way on the associated intrinsic.

But, if instead, the dummy array_ref were declared as
>> > integer, target :: array_ref(:)
then case 1 on page 84 applies and pointers that are
associated with the dummy remain associated with the dummy.

So, I think my original suggestion of making array_ref
assumed shape should do the right thing.

I agree that making array_ref an assumed-shape array
would fix the OP's sample program.

There was a huge multi-year interp about pointers and
targets against F95.

Yes, I recall seeing e-mail traffic about it. However, the
bulk of the work seems to have been done w.r.t. the
Fortran 90 standard, not Fortran 95. The third TC for
Fortran 90 contains the bulk of the edits that were made.
TC3 for Fortran 90 and the Fortran 95 standard were
developed simultaneously, and published at almost
the same time.

I think it all got cleaned up and
the net result was that, when passing targets to
assumed-shape targets, the compiler can't use copy-in/
copy-out; rather it must use "pass by address".

Yes, the processor must either use "call by reference"
(I readily admit your term "pass by address" is more
explicit), or something effectively equivalent to it.

It
was a mess. It's probably best to pour through the
F2003 stuff to see the actual final results. Although
that's a tough read because things are all tied up with
polymorphic stuff as well.

I am a bit concerned that the old material from the
Fortran 90 I cited in my argument is still present,
albeit in an altered form. I am afraid that a literal
reading of the standard would have it that programs
that are clearly intended to be standard-conforming
are not standard-conforming. I am also concerned
that there is no reference to the text you cited in
Section 12.4.1.2 of the Fortran 2003 standard in
Section 16.4.2.1.3 "Events that cause the association
status of pointers to become undefined."

Bob Corbett

.

Quantcast