From:  robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: A problem about Fortran pointers
Date: Sun, 01 Jul 2007 23:37:53 -0700
Message-ID: <1183358273.319390.160550@k29g2000hsd.googlegroups.com>

On Jul 1, 3:04 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:

> Ah.  So I still got it wrong.  Can't even complain I hadn't
> had morning coffee.  No excuses at all....
>
> Still, the conclusion I reached is valid: there really is no
> need for the pointer/descriptor of a rank-zero item to be
> anything other than an address.  Unless addresses are
> 32 bytes long, there's obviously room for improvement.
> Though my original theory that the descriptor was the same
> as what they used for rank-seven arrays can't be true.

The OP's example was about pointers to rank 1 arrays.
I doubt that CVF pointers to scalars require 32 bytes.
For all practical purposes, the smallest a pointer to a
rank 1 array for a 32-bit machine can be is 16 bytes:
four bytes for the address of the allocated data, and
12 bytes for information about extent, stride and
bounds.

Sun f95 uses 20 bytes for its pointers to rank 1 arrays
on 32-bit machines.  The extra four bytes is for a
virtual origin to facilitate subscripting.  The virtual
origin is redundant in that it can be computed from the
other fields of the pointer.

While is possible to implement pointers to scalars as
simple addresses, some additional information is required
for each entity allocated as a pointer target.  That
information is needed to satisfy the requirements placed
on the DEALLOCATE statement (see Section 6.3.3.2 of the
Fortran 2003 standard).  The Fortran processor must be
able to determine that the entity was allocated as a
pointer target and the size of the entity.  An obvious
implementation is to provide that additional information
as part of the pointer.

Sun f95 represents pointers to scalars as simple addresses
(four bytes on 32-bit architectures, 8 bytes on 64-bit
architectures).  It does not use the obvious scheme of
storing the additional information with the pointer.

Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: Rules for valid pointer deallocation
Date: 29 Jul 2006 01:48:58 -0700
Message-ID: <1154162938.195118.325380@b28g2000cwb.googlegroups.com>

Dick Hendrickson wrote:

> robert.corbett@sun.com 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