Re: A little pointer on POINTER in data would be helpful

Re: A little pointer on POINTER in data would be helpful

[Tim Zeisloft]

On 3/24/2018 2:35 AM, fortran-digest-help@gcc.gnu.org wrote:
> looking at the various versions of the program, I wonder if the data
> statement is supposed to work as an association. Normally one does:
>
> p => target_variable
> p = 1
>
> or the like, so first an explicit association via => (or an
> allocation) and then the assignment. A data statement simply assigns
> the values and can not refer to variables. Hence it seems unlikely
> that any of the above programs is standard conforming. With the
> possible exception of "data p / null() /".
I agree with Arjen that the data statement is restricted to assignment 
only, and does not allow or assume pointer assignment. If one accepts 
that the statement "data idata/1/" is the equivalent of "integer :: 
idata=1" then R505 dictates that the component initialization must be a 
constant expression, so the compiler reaction appears correct. It seems 
that C510 might also have something to say about the situation.
The result of the null() function is considered to be a data constant 
(R542), and the standard specifically describes it's use in a data 
statement in table 13.2. Another subtlety is that the appearance of the 
variable in the data statement results in rules for explicit 
initialization to override the rules for default initialization. One 
implication of this is that the object is automatically granted the save 
attribute when explicitly initialized while it is not when default 
initialization is used.

>     If data-stmt-constant is initial-data-target the corresponding
>     data statement object shall be data-pointer-initialization
>     compatible with the initial data target; the data statement
>     object is initially associated with the target.
>
> This is where it gets interesting.
>
> R443 initial-data-target  is designator
> R601 designator  is object-name
>                   or array-element
>                   or array-section
>                   or coindexed-named-object
>                   or complex-part-designator
>                   or structure-component
>                   or substring
>
> After bouncing around abit, one finds
>
>    C766  A designator that is an initial-data-target shall designate
>    a nonallocatable, noncoindexed variable that has the TARGET and
>    SAVE attributes and does not have a vector subscript.  Every
>    subscript, section subscript, substring starting point, and
>    substring ending point in designator shall be a constant expression.
>
> program p
>     integer, target, save :: m = 3
>     type t
>        integer, pointer :: n
>     end type
>     type(t) :: z
>     data z%n / m /
>     m = 3
>     print *, z%n
> end
>
> % gfcx -o z b.f90
> b.f90:7:15:
>
>      data z%n / m /
>                 1
> Error: Symbol 'm' must be a PARAMETER in DATA statement at (1)
>
> Whoops.

The rule R443 appears in the context of default initialization, but we 
are explicitly initializing because of the data statement, so R443 
doesn't seem to apply.
If one looks at the definition of what can appear in a 
data-stmt-value-list (5.4.7.6), everything must reduce to a constant 
expression, which confirms that the compiler is correctly diagnosing the 
situation.

Tim

Re: A little pointer on POINTER in data would be helpful

[Steve Kargl]

On Sat, Mar 24, 2018 at 01:08:58PM -0700, Tim Zeisloft wrote:
> > program p
> >     integer, target, save :: m = 3
> >     type t
> >        integer, pointer :: n
> >     end type
> >     type(t) :: z
> >     data z%n / m /
> >     m = 3
> >     print *, z%n
> > end
> >
> > % gfcx -o z b.f90
> > b.f90:7:15:
> >
> >      data z%n / m /
> >                 1
> > Error: Symbol 'm' must be a PARAMETER in DATA statement at (1)
> >
> > Whoops.
> 
> The rule R443 appears in the context of default initialization, but we 
> are explicitly initializing because of the data statement, so R443 
> doesn't seem to apply.
> If one looks at the definition of what can appear in a 
> data-stmt-value-list (5.4.7.6), everything must reduce to a constant 
> expression, which confirms that the compiler is correctly diagnosing the 
> situation.

I think the Fortran 2018 standard may disagree with you.

R837 data-stmt         is DATA data-stmt-set [ [ , ] data-stmt-set ] ...
R838 data-stmt-set     is data-stmt-object-list / data-stmt-value-list /
R839 data-stmt-object  is variable
                       or data-implied-do

C874 (R839) A data-stmt-object that is a variable shall be a designator.

C876 (R839) A data-i-do-object or a variable that appears as a
     data-stmt-object shall not be an object designator in which a pointer
     appears other than as the entire rightmost part-ref.

R843 data-stmt-value  is [ data-stmt-repeat * ] data-stmt-constant

R845 data-stmt-constant  is scalar-constant
                         or scalar-constant-subobject
                         or signed-int-literal-constant
                         or signed-real-literal-constant
                         or null-init
                         or initial-data-target      <-- Here's the problem
                         or structure-constructor

R744 initial-data-target  is designator

R901 designator   is object-name
R804 object-name  is name
R603 name         is letter [ alphanumeric-character ] ...

A data-stmt-constant shall be null-init or initial-data-target if and
only if the corresponding data-stmt-object has the POINTER attribute.
If data-stmt-constant is null-init, the initial association status of
the corresponding data statement object is disassociated.  If
data-stmt-constant is initial-data-target the corresponding data statement
object shall be data-pointer-initialization compatible (7.5.4.6) with the
initial data target; the data statement object is initially associated
with the target.

So, I believe the standard says the following code is conforming

subroutine sub(i)
   integer, intent(in) :: i
   integer, save, target :: j
   integer, pointer :: k
   data k/j/
   if (i /= 0) then
      j = i
   else
      j = 42
   end if
   print *, k
end subroutine

An equivalent subroutine would be

subroutine sub(i)
   integer, intent(in) :: i
   integer, save, target :: j
   integer, pointer :: k => j
   if (i /= 0) then
      j = i
   else
      j = 42
   end if
   print *, k
end subroutine

Of course, I could be wrong.

-- 
Steve

Re: A little pointer on POINTER in data would be helpful

[Steve Kargl]

On Sat, Mar 24, 2018 at 01:51:40PM -0700, Steve Kargl wrote:

(snip)

> 
> So, I believe the standard says the following code is conforming
> 
> subroutine sub(i)
>    integer, intent(in) :: i
>    integer, save, target :: j
>    integer, pointer :: k
>    data k/j/
>    if (i /= 0) then
>       j = i
>    else
>       j = 42
>    end if
>    print *, k
> end subroutine

(snip)

> 
> Of course, I could be wrong.
> 

Of course, finding a trivially stupid patch to accept the
above was easy.  Making sure that it doesn't allow anything
to go sideways is the challenge.  Still need to get some
confirmation that the above is valid.

-- 
Steve

Re: A little pointer on POINTER in data would be helpful

[Tim Zeisloft]

On 3/24/2018 1:51 PM, Steve Kargl wrote:
> On Sat, Mar 24, 2018 at 01:08:58PM -0700, Tim Zeisloft wrote:
>>> program p
>>>      integer, target, save :: m = 3
>>>      type t
>>>         integer, pointer :: n
>>>      end type
>>>      type(t) :: z
>>>      data z%n / m /
>>>      m = 3
>>>      print *, z%n
>>> end
>>>
>>> % gfcx -o z b.f90
>>> b.f90:7:15:
>>>
>>>       data z%n / m /
>>>                  1
>>> Error: Symbol 'm' must be a PARAMETER in DATA statement at (1)
>>>
>>> Whoops.
>> The rule R443 appears in the context of default initialization, but we
>> are explicitly initializing because of the data statement, so R443
>> doesn't seem to apply.
>> If one looks at the definition of what can appear in a
>> data-stmt-value-list (5.4.7.6), everything must reduce to a constant
>> expression, which confirms that the compiler is correctly diagnosing the
>> situation.
> I think the Fortran 2018 standard may disagree with you.
>
> R837 data-stmt         is DATA data-stmt-set [ [ , ] data-stmt-set ] ...
> R838 data-stmt-set     is data-stmt-object-list / data-stmt-value-list /
> R839 data-stmt-object  is variable
>                         or data-implied-do
>
> C874 (R839) A data-stmt-object that is a variable shall be a designator.
>
> C876 (R839) A data-i-do-object or a variable that appears as a
>       data-stmt-object shall not be an object designator in which a pointer
>       appears other than as the entire rightmost part-ref.
>
> R843 data-stmt-value  is [ data-stmt-repeat * ] data-stmt-constant
>
> R845 data-stmt-constant  is scalar-constant
>                           or scalar-constant-subobject
>                           or signed-int-literal-constant
>                           or signed-real-literal-constant
>                           or null-init
>                           or initial-data-target      <-- Here's the problem
>                           or structure-constructor
>
> R744 initial-data-target  is designator
>
> R901 designator   is object-name
> R804 object-name  is name
> R603 name         is letter [ alphanumeric-character ] ...
>
> A data-stmt-constant shall be null-init or initial-data-target if and
> only if the corresponding data-stmt-object has the POINTER attribute.
> If data-stmt-constant is null-init, the initial association status of
> the corresponding data statement object is disassociated.  If
> data-stmt-constant is initial-data-target the corresponding data statement
> object shall be data-pointer-initialization compatible (7.5.4.6) with the
> initial data target; the data statement object is initially associated
> with the target.
I would remark that my comments were based on the F2008 standard, as 
that is what was cited in the original post. Nonetheless, what you post 
looks similar.
>
> So, I believe the standard says the following code is conforming
>
> subroutine sub(i)
>     integer, intent(in) :: i
>     integer, save, target :: j
>     integer, pointer :: k
>     data k/j/
>     if (i /= 0) then
>        j = i
>     else
>        j = 42
>     end if
>     print *, k
> end subroutine
>
> An equivalent subroutine would be
>
> subroutine sub(i)
>     integer, intent(in) :: i
>     integer, save, target :: j
>     integer, pointer :: k => j
>     if (i /= 0) then
>        j = i
>     else
>        j = 42
>     end if
>     print *, k
> end subroutine
>
> Of course, I could be wrong.
For me, the question boils down to whether the data statement means "=" 
or whether it has been extended to also mean "=>". All specifications 
containing initial-data-target always show it to the right of "=>", not 
"=". It seems a perfectly reasonable interpretation to say that 
assignment with a data statement means "=", in which case 
initial-data-target cannot be used because it is only specified to the 
right of "=>". That said, your interpretation seems equally valid, 
provided we are extending the data statement to provide pointer 
assignment. I consider the data statement to be somewhat archaic, and 
would be disappointed at it being extended when the second example is so 
much cleaner.

Re: A little pointer on POINTER in data would be helpful

[Steve Kargl]

On Sat, Mar 24, 2018 at 03:45:30PM -0700, Tim Zeisloft wrote:
> On 3/24/2018 1:51 PM, Steve Kargl wrote:
> >
> > A data-stmt-constant shall be null-init or initial-data-target if and
> > only if the corresponding data-stmt-object has the POINTER attribute.
> > If data-stmt-constant is null-init, the initial association status of
> > the corresponding data statement object is disassociated.  If
> > data-stmt-constant is initial-data-target the corresponding data statement
> > object shall be data-pointer-initialization compatible (7.5.4.6) with the
> > initial data target; the data statement object is initially associated
> > with the target.
> I would remark that my comments were based on the F2008 standard, as 
> that is what was cited in the original post. Nonetheless, what you post 
> looks similar.

I just checked F2003.  It only has

R532 data-stmt-constant  is scalar-constant
                         or scalar-constant-subobject
                         or signed-int-literal-constant
                         or signed-real-literal-constant
                         or null-init
                         or structure-constructor

So, initial-data-target was added in F2008. 

> > So, I believe the standard says the following code is conforming
> >
> > subroutine sub(i)
> >     integer, intent(in) :: i
> >     integer, save, target :: j
> >     integer, pointer :: k
> >     data k/j/
> >     if (i /= 0) then
> >        j = i
> >     else
> >        j = 42
> >     end if
> >     print *, k
> > end subroutine
> >
> > Of course, I could be wrong.
> >
> For me, the question boils down to whether the data statement means "=" 
> or whether it has been extended to also mean "=>".

This is exactly what I think has been done.  It seems
that there is an assumption that SAVE and TARGET means
the address of 'j' above is 'constant'.  So, the data
statement associates 'k' with that address not 'j's
actually value.

> All specifications 
> containing initial-data-target always show it to the right of "=>", not 
> "=". It seems a perfectly reasonable interpretation to say that 
> assignment with a data statement means "=", in which case 
> initial-data-target cannot be used because it is only specified to the 
> right of "=>". That said, your interpretation seems equally valid, 
> provided we are extending the data statement to provide pointer 
> assignment. I consider the data statement to be somewhat archaic, and 
> would be disappointed at it being extended when the second example is so 
> much cleaner.

Same here with the disappointment.  Well, I'm subscribed to
the J3 mailing list.  I suppose I can send an email to the
list and ask.  I'll also hunt around for the J3 paper, which
provided the rationale and modification.

Oh, I also sent the above subroutine to comp.lang.fortran
so see what others have to say.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: A little pointer on POINTER in data would be helpful

[Steve Kargl]

On Sat, Mar 24, 2018 at 04:06:40PM -0700, Steve Kargl wrote:
> 
> > All specifications 
> > containing initial-data-target always show it to the right of "=>", not 
> > "=". It seems a perfectly reasonable interpretation to say that 
> > assignment with a data statement means "=", in which case 
> > initial-data-target cannot be used because it is only specified to the 
> > right of "=>". That said, your interpretation seems equally valid, 
> > provided we are extending the data statement to provide pointer 
> > assignment. I consider the data statement to be somewhat archaic, and 
> > would be disappointed at it being extended when the second example is so 
> > much cleaner.
> 
> Same here with the disappointment.  Well, I'm subscribed to
> the J3 mailing list.  I suppose I can send an email to the
> list and ask.  I'll also hunt around for the J3 paper, which
> provided the rationale and modification.

Well, I found N1828.pdf.  This is John Reid's "The new features
of Fortran 2008".   It has an entry for

  5.5 Pointer initialization

  A pointer may be initially associated with a target with the
  save attribute:
       type (entry), target, save :: bottom
       type (entry), pointer :: top => bottom

  and a pointer component may be default initialized as associated
  with a target.

There is no mention of DATA statement and initial-data-target change.

-- 
Steve

Re: A little pointer on POINTER in data would be helpful

[Tim Zeisloft]

On 3/24/2018 4:29 PM, Steve Kargl wrote:
> On Sat, Mar 24, 2018 at 04:06:40PM -0700, Steve Kargl wrote:
>>> All specifications
>>> containing initial-data-target always show it to the right of "=>", not
>>> "=". It seems a perfectly reasonable interpretation to say that
>>> assignment with a data statement means "=", in which case
>>> initial-data-target cannot be used because it is only specified to the
>>> right of "=>". That said, your interpretation seems equally valid,
>>> provided we are extending the data statement to provide pointer
>>> assignment. I consider the data statement to be somewhat archaic, and
>>> would be disappointed at it being extended when the second example is so
>>> much cleaner.
>> Same here with the disappointment.  Well, I'm subscribed to
>> the J3 mailing list.  I suppose I can send an email to the
>> list and ask.  I'll also hunt around for the J3 paper, which
>> provided the rationale and modification.
> Well, I found N1828.pdf.  This is John Reid's "The new features
> of Fortran 2008".   It has an entry for
>
>    5.5 Pointer initialization
>
>    A pointer may be initially associated with a target with the
>    save attribute:
>         type (entry), target, save :: bottom
>         type (entry), pointer :: top => bottom
>
>    and a pointer component may be default initialized as associated
>    with a target.
>
> There is no mention of DATA statement and initial-data-target change.
>
After some consideration on the matter, I realize my statement about 
initial-data-target is on very shaky ground because it does not make 
sense that it cannot be used, yet is named as being permitted within a 
data statement. Since initial-data-target only ever occurs to the right 
of "=>" I have to now submit that the extension to "=>" has been made 
like it or not. This seems to be the only clue that pointer assignment 
is allowed in this context. I note that the data statement does not 
appear in any examples of pointer assignment in the F2008 standard.

Re: A little pointer on POINTER in data would be helpful

[Steve Kargl]

Arjen,

Thanks for the feedback.

First two are definitely invalid and I think I know where
to try to check for the problem in gfortran.  The third one
with null() is fine.  It's the last one that has me 
scratch my head.  It seems that "data p /m/" with 
m having the target and save attribute is meant to be
interpreted as "p => m". I freely admit that I sometime
has trouble parsing the standard.

-- 
steve

On Fri, Mar 23, 2018 at 10:47:54AM +0100, Arjen Markus wrote:
> Hello Steve,
> 
> looking at the various versions of the program, I wonder if the data
> statement is supposed to work as an association. Normally one does:
> 
> p => target_variable
> p = 1
> 
> or the like, so first an explicit association via => (or an
> allocation) and then the assignment. A data statement simply assigns
> the values and can not refer to variables. Hence it seems unlikely
> that any of the above programs is standard conforming. With the
> possible exception of "data p / null() /".
> 
> Regards,
> 
> Arjen
> 
> 
> 2018-03-23 0:38 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> > I don't use POINTERs in my codes, so have little
> > experience with them; especially when derived types
> > are involved.  In PR 70870, Gerhard added the code
> >
> > program p
> >    type t
> >       integer :: n
> >    end type
> >    type(t), pointer :: z
> >    data z%n / 3 /
> >    print *, z%n
> > end
> >
> > which results in an ICE.  I'm trying to parse
> >
> >   F2008:C567 (R536) A data-i-do-object or a variable
> >   that appears as a data-stmt-object shall not be an
> >   object designator in which a pointer appears other
> >   than as the entire rightmost part-ref.
> >
> > My understanding is that the POINTER attribute applied
> > to z, which is not the rightmost part-ref.  The rightmost
> > is n.  Thus, the above code is violates a constraint.  I
> > think I know where to fix this situation.
> >
> > So, I now, re-arrange the above code to
> >
> > program p
> >    type t
> >       integer, pointer :: n
> >    end type
> >    type(t) :: z
> >    data z%n / 3 /
> >    print *, z%n
> > end
> >
> > Here, the POINTER attribute applies to the component n,
> > and so it is the rightmost part.  This code actually
> > compiles, but segfaults on execution, which may be
> > expected as '3' is not a TARGET.  The code is invalid,
> > but gfortran is not required to issues an error message.
> > The standard goes on to say
> >
> >    A data-stmt-constant shall be null-init or initial-data-target
> >    if and only if the corresponding data-stmt-object has the
> >    POINTER attribute.  If data-stmt-constant is null-init, the initial
> >    association status of the corresponding data statement object is
> >    disassociated.
> >
> > OK, so change the code to
> >
> > program p
> >    type t
> >       integer, pointer :: n
> >    end type
> >    type(t) :: z
> >    data z%n / null() /
> >    print *, associated(z%n)
> > end
> >
> > % gfcx -o z b.f90 && ./z
> >  F
> >
> > Good, gfortran gets this correct.  The stand goes on to say
> >
> >    If data-stmt-constant is initial-data-target the corresponding
> >    data statement object shall be data-pointer-initialization
> >    compatible with the initial data target; the data statement
> >    object is initially associated with the target.
> >
> > This is where it gets interesting.
> >
> > R443 initial-data-target  is designator
> > R601 designator  is object-name
> >                  or array-element
> >                  or array-section
> >                  or coindexed-named-object
> >                  or complex-part-designator
> >                  or structure-component
> >                  or substring
> >
> > After bouncing around abit, one finds
> >
> >   C766  A designator that is an initial-data-target shall designate
> >   a nonallocatable, noncoindexed variable that has the TARGET and
> >   SAVE attributes and does not have a vector subscript.  Every
> >   subscript, section subscript, substring starting point, and
> >   substring ending point in designator shall be a constant expression.
> >
> > program p
> >    integer, target, save :: m = 3
> >    type t
> >       integer, pointer :: n
> >    end type
> >    type(t) :: z
> >    data z%n / m /
> >    m = 3
> >    print *, z%n
> > end
> >
> > % gfcx -o z b.f90
> > b.f90:7:15:
> >
> >     data z%n / m /
> >                1
> > Error: Symbol 'm' must be a PARAMETER in DATA statement at (1)
> >
> > Whoops.
> >
> > --
> > Steve

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: A little pointer on POINTER in data would be helpful

[Arjen Markus]

Hello Steve,

looking at the various versions of the program, I wonder if the data
statement is supposed to work as an association. Normally one does:

p => target_variable
p = 1

or the like, so first an explicit association via => (or an
allocation) and then the assignment. A data statement simply assigns
the values and can not refer to variables. Hence it seems unlikely
that any of the above programs is standard conforming. With the
possible exception of "data p / null() /".

Regards,

Arjen


2018-03-23 0:38 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> I don't use POINTERs in my codes, so have little
> experience with them; especially when derived types
> are involved.  In PR 70870, Gerhard added the code
>
> program p
>    type t
>       integer :: n
>    end type
>    type(t), pointer :: z
>    data z%n / 3 /
>    print *, z%n
> end
>
> which results in an ICE.  I'm trying to parse
>
>   F2008:C567 (R536) A data-i-do-object or a variable
>   that appears as a data-stmt-object shall not be an
>   object designator in which a pointer appears other
>   than as the entire rightmost part-ref.
>
> My understanding is that the POINTER attribute applied
> to z, which is not the rightmost part-ref.  The rightmost
> is n.  Thus, the above code is violates a constraint.  I
> think I know where to fix this situation.
>
> So, I now, re-arrange the above code to
>
> program p
>    type t
>       integer, pointer :: n
>    end type
>    type(t) :: z
>    data z%n / 3 /
>    print *, z%n
> end
>
> Here, the POINTER attribute applies to the component n,
> and so it is the rightmost part.  This code actually
> compiles, but segfaults on execution, which may be
> expected as '3' is not a TARGET.  The code is invalid,
> but gfortran is not required to issues an error message.
> The standard goes on to say
>
>    A data-stmt-constant shall be null-init or initial-data-target
>    if and only if the corresponding data-stmt-object has the
>    POINTER attribute.  If data-stmt-constant is null-init, the initial
>    association status of the corresponding data statement object is
>    disassociated.
>
> OK, so change the code to
>
> program p
>    type t
>       integer, pointer :: n
>    end type
>    type(t) :: z
>    data z%n / null() /
>    print *, associated(z%n)
> end
>
> % gfcx -o z b.f90 && ./z
>  F
>
> Good, gfortran gets this correct.  The stand goes on to say
>
>    If data-stmt-constant is initial-data-target the corresponding
>    data statement object shall be data-pointer-initialization
>    compatible with the initial data target; the data statement
>    object is initially associated with the target.
>
> This is where it gets interesting.
>
> R443 initial-data-target  is designator
> R601 designator  is object-name
>                  or array-element
>                  or array-section
>                  or coindexed-named-object
>                  or complex-part-designator
>                  or structure-component
>                  or substring
>
> After bouncing around abit, one finds
>
>   C766  A designator that is an initial-data-target shall designate
>   a nonallocatable, noncoindexed variable that has the TARGET and
>   SAVE attributes and does not have a vector subscript.  Every
>   subscript, section subscript, substring starting point, and
>   substring ending point in designator shall be a constant expression.
>
> program p
>    integer, target, save :: m = 3
>    type t
>       integer, pointer :: n
>    end type
>    type(t) :: z
>    data z%n / m /
>    m = 3
>    print *, z%n
> end
>
> % gfcx -o z b.f90
> b.f90:7:15:
>
>     data z%n / m /
>                1
> Error: Symbol 'm' must be a PARAMETER in DATA statement at (1)
>
> Whoops.
>
> --
> Steve

A little pointer on POINTER in data would be helpful

[Steve Kargl]

I don't use POINTERs in my codes, so have little
experience with them; especially when derived types
are involved.  In PR 70870, Gerhard added the code 

program p
   type t
      integer :: n
   end type
   type(t), pointer :: z
   data z%n / 3 /
   print *, z%n
end

which results in an ICE.  I'm trying to parse

  F2008:C567 (R536) A data-i-do-object or a variable
  that appears as a data-stmt-object shall not be an
  object designator in which a pointer appears other
  than as the entire rightmost part-ref.

My understanding is that the POINTER attribute applied
to z, which is not the rightmost part-ref.  The rightmost
is n.  Thus, the above code is violates a constraint.  I
think I know where to fix this situation.

So, I now, re-arrange the above code to

program p
   type t
      integer, pointer :: n
   end type
   type(t) :: z
   data z%n / 3 /
   print *, z%n
end

Here, the POINTER attribute applies to the component n,
and so it is the rightmost part.  This code actually
compiles, but segfaults on execution, which may be 
expected as '3' is not a TARGET.  The code is invalid,
but gfortran is not required to issues an error message.
The standard goes on to say 

   A data-stmt-constant shall be null-init or initial-data-target
   if and only if the corresponding data-stmt-object has the
   POINTER attribute.  If data-stmt-constant is null-init, the initial
   association status of the corresponding data statement object is
   disassociated.

OK, so change the code to

program p
   type t
      integer, pointer :: n
   end type
   type(t) :: z
   data z%n / null() /
   print *, associated(z%n)
end

% gfcx -o z b.f90 && ./z
 F

Good, gfortran gets this correct.  The stand goes on to say

   If data-stmt-constant is initial-data-target the corresponding
   data statement object shall be data-pointer-initialization
   compatible with the initial data target; the data statement
   object is initially associated with the target.

This is where it gets interesting.

R443 initial-data-target  is designator
R601 designator  is object-name
                 or array-element
                 or array-section
                 or coindexed-named-object
                 or complex-part-designator
                 or structure-component
                 or substring

After bouncing around abit, one finds

  C766  A designator that is an initial-data-target shall designate
  a nonallocatable, noncoindexed variable that has the TARGET and
  SAVE attributes and does not have a vector subscript.  Every
  subscript, section subscript, substring starting point, and
  substring ending point in designator shall be a constant expression.

program p
   integer, target, save :: m = 3
   type t
      integer, pointer :: n
   end type
   type(t) :: z
   data z%n / m /
   m = 3
   print *, z%n
end

% gfcx -o z b.f90
b.f90:7:15:

    data z%n / m /
               1
Error: Symbol 'm' must be a PARAMETER in DATA statement at (1)

Whoops.

-- 
Steve