association with zero-length array?
Oskar Enoksson
I have a zero-sized array with TARGET attribute. I associate an array
pointer with my array. But when using the ASSOCIATED intrinsic later on
to determine if the pointer is still associated with the zero-sized
array I always get .FALSE. Is this really supposed to happen?
INTEGER, TARGET :: EMPTY(0)
INTEGER, POINTER :: PTR(:)
PTR => EMPTY
WRITE(*,*) ASSOCIATED(PTR,EMPTY)
> ifort -o tst tst.f90 && ./tst
F
>
Arjen Markus
wrote:
I tried this program with g95 and gfortran - both return true
(ifort indeed returns false).
I would expect "true", as zero-length arrays are supposed
to behave in the same way as any other array.
A further indication that ifort is giving the wrong answer
is that ASSOCIATED(PTR) returns true in all three cases.
Regards,
Arjen
Steve Lionel
> I tried this program with g95 and gfortran - both return true
> (ifort indeed returns false).
>
> I would expect "true", as zero-length arrays are supposed
> to behave in the same way as any other array.
>
> A further indication that ifort is giving the wrong answer
> is that ASSOCIATED(PTR) returns true in all three cases.
My reading of the standard suggests to me that ifort is correct and
g95 and gfortran are incorrect in this case.
In the description of ASSOCIATED, F2003 p305, lines 5-9. it says
(emphasis mine):
Case (v): If TARGET is present and is an array target, the result is
true if the target associated with POINTER and TARGET have the same
shape, are *neither of size zero* nor arrays whose elements are zero-
sized storage sequences, and occupy the same storage units in array
element order. Otherwise, the result is false. If POINTER is
disassociated, the result is false.
Since EMPTY is of size zero, it disqualifies a true result.
I welcome other opinions.
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Tobias Burnus
> On Aug 15, 9:21 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> > I tried this program with g95 and gfortran - both return true
> > (ifort indeed returns false).
gfortran 4.1 returns TRUE as does openf95 4.0; however, gfortran 4.2.x/
4.3.0 and g95 0.91 as well as NAG f95, sunf95 and ifort return FALSE.
Tobias,
who agrees with Steve's analysis
jwm
wrote:
> I have a zero-sized array with TARGET attribute. I associate an array
> pointer with my array. But when using the ASSOCIATED intrinsic later on
> to determine if the pointer is still associated with the zero-sized
> array I always get .FALSE. Is this really supposed to happen?
I'm not sure about the purpose of your question.
Are you expecting the pointer to be associated with nothing? The
reason you always get .FALSE. is because your EMPTY array is actually
empty. What I mean to say is that your definition of EMPTY is
equivalent to:
INTEGER, TARGET :: EMPTY(1:0)
What you have is actually a zero-sized array ---and maybe what you
want is a zero-based array.
gfortran (v. 4.3.0) returns .FALSE. as well, and therefore I would
discard it as a bug in ifort.
Arjen Markus
> On Aug 15, 9:21 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
> > I tried this program with g95 and gfortran - both return true
> > (ifort indeed returns false).
>
> > I would expect "true", as zero-length arrays are supposed
> > to behave in the same way as any other array.
>
> > A further indication that ifort is giving the wrong answer
> > is that ASSOCIATED(PTR) returns true in all three cases.
>
> My reading of the standard suggests to me that ifort is correct and
> g95 and gfortran are incorrect in this case.
>
> In the description of ASSOCIATED, F2003 p305, lines 5-9. it says
> (emphasis mine):
>
> Case (v): If TARGET is present and is an array target, the result is
> true if the target associated with POINTER and TARGET have the same
> shape, are *neither of size zero* nor arrays whose elements are zero-
> sized storage sequences, and occupy the same storage units in array
> element order. Otherwise, the result is false. If POINTER is
> disassociated, the result is false.
>
> Since EMPTY is of size zero, it disqualifies a true result.
>
> I welcome other opinions.
>
No, with that description the answer should indeed be true.
But how come the pointer is associated? Doesn't that constitute
a contradiction? The pointer is associated but not to what it
was associated with in the first place.
Regards,
Arjen (who seems to have fairly old versions of the various
compilers :()
Steve Lionel
> No, with that description the answer should indeed be true.
> But how come the pointer is associated? Doesn't that constitute
> a contradiction? The pointer is associated but not to what it
> was associated with in the first place.
I don't see how you reach the conclusion that the answer should be
true. The text is quite clear that if either POINTER or TARGET is of
size zero that the result of ASSOCIATED must be false.
What you see as a contradiction is simply the result of ASSOCIATED
meaning different things depending on whether or not TARGET is
specified. If TARGET is absent, then the standard says "the result is
true if POINTER is associated with a target and false if not".
I understand your confusion, but I also understand why the standard
goes out of its way to exclude zero-sized arrays as you could get even
more confusing results with other programs if it didn't.
Steve
James Van Buskirk
news:1187187208.3...@x35g2000prf.googlegroups.com...
> I understand your confusion, but I also understand why the standard
> goes out of its way to exclude zero-sized arrays as you could get even
> more confusing results with other programs if it didn't.
Could you provide us with an example or two of such confusing results?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Steve Lionel
>
> Could you provide us with an example or two of such confusing results?
Off the top of my head, no. The text I cited was added to the
language in F95 due to F90 Interpretation 27, which I append below.
The idea seems to be that if one of the arrays is zero sized, there
are no elements which are "the same storage units in array element
order". An array with no elements has no allocated storage, so how
can one ask if a pointer shares the same storage?
Here's the text of the interp:
NUMBER: 000027
TITLE: Requirements for pointer and target association
KEYWORDS: POINTER attribute, TARGET attribute, pointer association
DEFECT TYPE: Erratum
STATUS: WG5 approved; ready for SC22
QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or
POINTER attribute, under which of the following other conditions are
PTR
and TGT considered to be pointer associated, i.e., under which of the
following conditions does ASSOCIATED(PTR, TGT) return a value
of .TRUE.:
a) PTR and TGT have different types?
b) PTR and TGT have different type parameters?
c) PTR and TGT have different ranks?
d) PTR and TGT have different sizes?
e) PTR and TGT have different shapes?
f) PTR and TGT have different bounds?
g) PTR and TGT refer to the same set of array elements/storage units,
but
not in the same array element order?
h) PTR and TGT have array elements/storage units whose range of memory
addresses
overlap, but they have no identical array elements/storage units?
i) PTR and TGT have at least one but not all identical array
elements/storage units and all the identical elements have the same
subscript order value in both PTR and TGT?
j) PTR and TGT have at least one but not all identical array
elements/storage units but not all the identical elements have the
same sub
script order value in both PTR and TGT?
ANSWER: The conditions d), e), g), h), i) and j) are sufficient for
ASSOCIATED (PTR, TGT) to return a value of .FALSE.. The conditions
a), b), c)
and d) are such that if any are true, ASSOCIATED (PTR, TGT) is an
invalid
reference. In determining whether a pointer and a target are
associated, the
bounds are relevant only for determining which elements are
referenced. The
extents of each dimension of PTR and TGT must be the same, thus their
shapes
must match which is covered by condition (e). If TGT is zero sized,
ASSOCIATED
(PTR, TGT) returns .FALSE..
Discussion: It is the intent of the standard that the two argument
form of
the ASSOCIATED intrinsic function returns true only if the association
of
POINTER and TARGET is as if the pointer assignment statement
POINTER => TARGET
was the last statement executed prior to the execution of the
statement
invoking the ASSOCIATED function. This is not clear in the
definition of
the ASSOCIATED intrinsic or elsewhere in the standard. Clarifying
edits
are provided.
EDITS:
1. In section 13.13.13 [198:31] in the description of the TARGET dummy
argument
add
", and have the same type, type parameters, and rank as
POINTER"
following
"must be a pointer or target"
2. In section 13.13.13 replace Case (ii) with [198:37-38]
"Case (ii): If TARGET is present and is a scalar target, the
result is true if TARGET is not a zero-sized
storage
sequence and the target associated with POINTER
occupies
the same storage units as TARGET. Otherwise the
result is
false. If POINTER is disassociated, the result
is false."
3. In section 13.13.13 replace Case (iii) [199:1-3] with
"Case (iii): If TARGET is present and is an array target, the
result is true if the target associated with
POINTER and
TARGET have the same shape, are neither of size
zero nor
arrays whose elements are zero-sized storage
sequences,
and occupy the same storage units in array
element order.
Otherwise the result is false. If POINTER is
disassociated, the result is false.
Case (iv): If TARGET is present and is a scalar pointer,
the
result is true if the target associated with
POINTER and
the target associated with TARGET are not zero-
sized
storage sequences and they occupy the same
storage units
Otherwise the result is false. If either
POINTER or
TARGET is disassociated, the result is false.
Case (v): If TARGET is present and is an array pointer,
the result
is true if the target associated with POINTER
and the
target associated with TARGET have the same
shape, are
neither of size zero nor arrays whose elements
are
zero-sized storage sequences, and occupy the
same storage
units in array element order. Otherwise the
result is
false. If either POINTER or TARGET is
disassociated, the
result is false."
SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022)
HISTORY: 120-LJM-3A (120.081A)
m121 Original response proposed
92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned
response
(121-ADT-13) item 27
92-093A m121 Approved
92-329 (jw note)
m123 Approval rescinded at m123 (uc)
93-099r1 m124 Revised response adopted (15-2)
93-111 m125 ballot failed, returned to subgroup
93-135r m125 Based on comments returned with the X3J3 letter
ballot following m124, the revised response
was
prepared and adopted 15-3.
93-255r1 m127 ballot failed 17-7
94-289 m130 revised answer, approved u.c.
94-306 m131 X3J3 ballot failed 16-3
95-281 m135 revised response, added edits, WG5 approved
96- m136 X3J3 ballot approved 15-1, retains WG5 approval
-------------------------------------------------------------------------------
Steve
glen herrmannsfeldt
> Off the top of my head, no. The text I cited was added to the
> language in F95 due to F90 Interpretation 27, which I append below.
> The idea seems to be that if one of the arrays is zero sized, there
> are no elements which are "the same storage units in array element
> order". An array with no elements has no allocated storage, so how
> can one ask if a pointer shares the same storage?
You could also say that all the array elements share the
same storage.
Note that the ALL function applied to a zero length array
returns .TRUE., which I believe is the mathematically correct
result.
I do agree that if only one has zero size then the lengths are
different and they are not associated.
Even if the standard is wrong, though, compilers should follow
the standard.
-- glen
Oskar Enoksson
Thanks for responding. I guess ASSOCIATED usually is implemented to
compare the address of the first element and if there is no such element
there is no obvious way to tell if a pointer is associated with a
target. Seems well motivated to always return FALSE.
Perhaps a compiler could issue a warning when calling ASSOCIATED(x,y)
and any of x and y is known at compile time to be zero-sized (because
the result is always FALSE).
/Oskar
highegg
> Perhaps a compiler could issue a warning when calling ASSOCIATED(x,y)
> and any of x and y is known at compile time to be zero-sized (because
> the result is always FALSE).
>
> /Oskar
Possibly, but one very seldom creates such arrays or array sections.
Usually a zero-sized section comes out at runtime as a special case.
John Harper
Arjen Markus <arjen....@wldelft.nl> wrote:
>On 15 aug, 14:43, Oskar Enoksson <enok_tabort...@lysator.liu.se>
>wrote:
>> I stumbled upon an unexpected problem ...
>>
>> I have a zero-sized array with TARGET attribute. I associate an array
>> pointer with my array. But when using the ASSOCIATED intrinsic later on
>> to determine if the pointer is still associated with the zero-sized
>> array I always get .FALSE. Is this really supposed to happen?
>>
>> INTEGER, TARGET :: EMPTY(0)
>> INTEGER, POINTER :: PTR(:)
>>
>> PTR => EMPTY
>>
>> WRITE(*,*) ASSOCIATED(PTR,EMPTY)
>>
>> > ifort -o tst tst.f90 && ./tst
>> F
>> >
>
>I tried this program with g95 and gfortran - both return true
>(ifort indeed returns false).
Sun Fortran 95 8.3 SunOS_sparc Patch 127000-01 2007/07/18 writes F
On our machines using gcc 4.0.3, g95 core-dumps at run-time. More recent
versions of gcc may do something different. Our old NAG f95 compiler
also core-dumps at run time, saying
Reference to undefined POINTER PTR
Program terminated by fatal error
Our old Compaq f95 says at run time
forrtl: severe (139): array index out of bounds for index 1 (SIGTRAP)
Is the program standard-conforming?
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
John Harper
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>Even if the standard is wrong, though, compilers should follow
>the standard.
>
>-- glen
>
Recently, believing MR&C on optional dummy arguments of MAX, I sent a
bug report to a vendor whose f95 core-dumped at run time after the
first PRINT statement in this program:
PROGRAM testoptarg
PRINT *, m1(3,4)
PRINT *, m1(3)
PRINT *, m1()
CONTAINS
INTEGER FUNCTION m1(a1,a2)
INTEGER, OPTIONAL, INTENT(IN) :: a1,a2
m1 = max(1, 2, a1, a2) ! are args of max after the 2nd optional?
END FUNCTION m1
END PROGRAM testoptarg
The vendor's reply was
< It is a subtle point. The program would be standard conforming
< if the dummy arguments to MAX beyond the second dummy argument
< are optional. Section 13.2 of the Fortran 2003 standard states
< Many of the intrinsic procedures have optional arguments.
< The arguments are identified by the notation "optional"
< in the argument descriptions. In addition, the names of
< the optional arguments are enclosed in square brackets in
< description heading and in lists of procedures.
< The arguments to MAX do not have the notation "optional" in the
< argument description for MAX, but the arguments beyond the
< second argument are enclosed in square brackets.
However http://j3-fortran.org/doc/standing/links/015.txt contains
an interp saying that "optional" should have been in the description
of MAX in f95 13.14.64, and that that would go in F95 Corrigendum 3
if there were one. The correction does not appear in f2008 13.7.114.
Is the vendor referred to above right, or should I send bug reports to
the authors of MR&C and the vendors of compilers that executed all
three PRINT statements?
James Van Buskirk
news:1187254179.8...@r34g2000hsd.googlegroups.com...
> Possibly, but one very seldom creates such arrays or array sections.
> Usually a zero-sized section comes out at runtime as a special case.
It seems to me that zero-sized arrays may profitably be used also
with premeditation. What do you get if you try:
a =
reshape(zero_size%real_8,shape(a),reshape((/1.0_dp/),(/size(a,1)/)+1,(/0.0_dp/)))
where zero_size%real_8 is a zero-sized array? Obviously simpler in f03.
And they're just ducky for storing 'specification variables':
function fun(a)
real(dp), intent(in) :: a(:)
integer
my_specification_variable(huge(0):my_expensive_specification_function(size(a,1)))
real(dp) b(2*ubound(my_specification_variable,1)+5)
real(dp) c(3*ubound(my_specification_variable,1)+7)
real(dp) fun(size(b,1)+1,0:size(c,1))
...
This kind of syntax tends to be unloved by compilers, however.
Jan Vorbrüggen
> TITLE: Requirements for pointer and target association
> KEYWORDS: POINTER attribute, TARGET attribute, pointer association
> DEFECT TYPE: Erratum
> STATUS: WG5 approved; ready for SC22
> SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022)
> HISTORY: 120-LJM-3A (120.081A)
> m121 Original response proposed
> 92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned
> response
> (121-ADT-13) item 27
> 92-093A m121 Approved
> 92-329 (jw note)
> m123 Approval rescinded at m123 (uc)
> 93-099r1 m124 Revised response adopted (15-2)
> 93-111 m125 ballot failed, returned to subgroup
> 93-135r m125 Based on comments returned with the X3J3 letter
> ballot following m124, the revised response
> was
> prepared and adopted 15-3.
> 93-255r1 m127 ballot failed 17-7
> 94-289 m130 revised answer, approved u.c.
> 94-306 m131 X3J3 ballot failed 16-3
> 95-281 m135 revised response, added edits, WG5 approved
> 96- m136 X3J3 ballot approved 15-1, retains WG5 approval
That one seems to have been pretty contentious, given that it took four years
and four revisisions of the original accepted response...
Jan
Oskar Enoksson
> "highegg" <hig...@gmail.com> wrote in message
> news:1187254179.8...@r34g2000hsd.googlegroups.com...
>
>> Possibly, but one very seldom creates such arrays or array sections.
>> Usually a zero-sized section comes out at runtime as a special case.
>
> It seems to me that zero-sized arrays may profitably be used also
> with premeditation. What do you get if you try:
>
> a =
> reshape(zero_size%real_8,shape(a),reshape((/1.0_dp/),(/size(a,1)/)+1,(/0.0_dp/)))
>
> where zero_size%real_8 is a zero-sized array? Obviously simpler in f03.
> And they're just ducky for storing 'specification variables':
>
> function fun(a)
> real(dp), intent(in) :: a(:)
> integer
> my_specification_variable(huge(0):my_expensive_specification_function(size(a,1)))
> real(dp) b(2*ubound(my_specification_variable,1)+5)
> real(dp) c(3*ubound(my_specification_variable,1)+7)
> real(dp) fun(size(b,1)+1,0:size(c,1))
> ...
>
> This kind of syntax tends to be unloved by compilers, however.
My original idea was to initialize a pointer component of a derived type
to something with size zero, so that I could e.g. call SIZE(X%PTR) at
all times without ever needing to test the association status first, and
saving execution time by avoiding an ALLOCATE call in the "constructor".
I understand now why this doesn't work. A general conclusion seems to be
that the two-argument version of ASSOCIATED is somewhat dangerous for
array pointers.
INTEGER, TARGET :: EMPTY(0)
TYPE X_T
INTEGER, POINTER :: PTR(:)
END TYPE X_T
SUBROUTINE ALLOCATE_X(X,LEN)
TYPE(X_T), POINTER :: X
INTEGER, OPTIONAL :: LEN
ALLOCATE(X)
IF(PRESENT(LEN)) THEN
ALLOCATE(X%PTR(LEN))
ELSE
X%PTR => EMPTY
END IF
END SUBROUTINE ALLOCATE_X
SUBROUTINE DEALLOCATE_X(X)
TYPE(X_T), POINTER :: X
IF(.NOT.ASSOCIATED(X%PTR,EMPTY)) & ! Unexpectedly always FALSE
DEALLOCATE(X%PTR)
DEALLOCATE(X)
END SUBROUTINE DEALLOCATE_X
Richard Maine
[asks about association of zero-sized arrays]
Association of zero-sized arrays is a horrible mess. I personally find
it completely counter-intuitive. But then, it turns out that the "other"
answer is counterintuitive to other people. And what I'd think to be the
best answer doesn't work at all because of interaction with storage
association issues. (Now if pointers and targets had been disallowed
from COMMON and equivalence, things might heve been different, but that
bridge was passed over too long ago).
I've been away a few days, too tired to elaborate well tonight, and
probably won't get back to it after working off backlog. So about all I
can say is that my personal recommendation is to avoid doing anythig at
all with the two-argument form of the associated intrinsic and
zero-sized arrays. Pretty much whatever you do is bound to end up wrong
somewhere or other.
The one-argument form is fine. Nothing odd about it. It is the
two-argument form that has all the "issues". As someone else noted, the
one- and two-argument forms are really completely different
functionalities.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
robert....@sun.com
I am the vendor representative cited. After the reading the
interpretation, I agreed that the optional actual arguments
should be allowed. Even if the interpretation had gone the
other way, there would be no reason to send a bug report to the
vendors of the compilers that executed all three PRINT
statements. In that case, the program would not have been
standard-conforming, and any behavior would be permitted.
In my response, I said that I hate the committee's practice of
not fixing problems in the standard such as this one. The people
who filed the request for interpretation were two senior members
of the committee. If they found it unclear, I find it hard to
accept the statement in the interpretation that "the intent is
clear."
Bob Corbett
Oskar Enoksson
> Oskar Enoksson <enok_ta...@lysator.liu.se> wrote:
>
> [asks about association of zero-sized arrays]
>
> Association of zero-sized arrays is a horrible mess. I personally find
> it completely counter-intuitive. But then, it turns out that the "other"
> answer is counterintuitive to other people. And what I'd think to be the
> best answer doesn't work at all because of interaction with storage
> association issues. (Now if pointers and targets had been disallowed
> from COMMON and equivalence, things might heve been different, but that
> bridge was passed over too long ago).
>
> I've been away a few days, too tired to elaborate well tonight, and
> probably won't get back to it after working off backlog. So about all I
> can say is that my personal recommendation is to avoid doing anythig at
> all with the two-argument form of the associated intrinsic and
> zero-sized arrays. Pretty much whatever you do is bound to end up wrong
> somewhere or other.
>
> The one-argument form is fine. Nothing odd about it. It is the
> two-argument form that has all the "issues". As someone else noted, the
> one- and two-argument forms are really completely different
> functionalities.
Thanks. I'll stay away from the two-form of ASSOCIATED for array targets
in the future unless I'm sure they can't be zero-sized.
/Oskar
Craig Powers
I find it interesting that the following statement is made:
> Discussion: It is the intent of the standard that the two argument
> form of the ASSOCIATED intrinsic function returns true only if the
> association of POINTER and TARGET is as if the pointer assignment
> statement
>
> POINTER => TARGET
>
> was the last statement executed prior to the execution of the
> statement invoking the ASSOCIATED function.
And then it proceeds to not be true if TARGET is a zero-length array.
glen herrmannsfeldt
(snip)
> > association of POINTER and TARGET is as if the pointer assignment
> > statement
>> POINTER => TARGET
>> was the last statement executed prior to the execution of the
>> statement invoking the ASSOCIATED function.
> And then it proceeds to not be true if TARGET is a zero-length array.
I agree. It might be that it is too late to change, but it seems
inconsistent also with the definition of the ALL function.
To make it more obvious, ALL elements of two zero length
arrays are associated.
-- glen