J3/16-103
To: J3 Members
From: Stan Whitlock
Subject: Results of the J3 Fortran interp letter ballot #34
Date: 2015 December 03
SW> Stan's comments below are marked with "SW>"
MJC Malcolm's replies are marked with MJC.
Here are the results of J3 letter ballot #34 on Fortran
interpretations that officially closed 20-Nov-2015. The ballot is
in J3 paper 16-101 for meeting #209. If I have transcribed a vote
or a comment incorrectly, please let me know.
J3 rep F03 F08 F08 F08 F08
/ interp 042 109 145 147 148
result of LB #34 Y A Y A A
Daniel Chen Y Y Y Y Y
Tom Clune Y Y Y Y Y
Malcolm Cohen C
Robert Corbett C Y Y C Y
Mark Leair Y Y Y Y Y
Bill Long Y Y Y Y Y
Toon Moene Y Y Y Y Y
Dan Nagle Y Y Y Y Y
John Reid Y C Y Y C
Van Snyder Y Y Y Y Y
Stan Whitlock Y Y Y Y Y
where Y means "yes"
C "yes with comment"
N "no with comment"
The comments for each interp are attached below in the same order as
the table above.
The interps marked "Y" pass with no change. The interps marked "A"
pass with some minor fixes, as noted below. The interps marked "N"
fail.
The edited interps in their final form are attached and will appear
in the next version 006.
/Stan
************************************************************************
F03/0042 IEEE funny values and Standard real generic intrinsic procedures
Robert Corbett's yes vote comment on F03/0042:
I agree that the language of the standard no longer requires processors
that implement IEEE floating-point arithmetic to signal exceptions in
cases where they should not.
I find some of Fred Tydeman's suggestions better than what the standard
specifies. For example, I think he is correct that SPACING should
return +infinity if the argument is an infinity.
Result for F03/0042:
/interp does not accept the suggestion that spacing (+infinity) should
be infinity. SPACING is the spacing between model numbers near the
argument. There are no model numbers near infinity and the spacing
of model numbers is never anywhere near infinity. Returning NaN is
therefore very reasonable. In fact, all model numbers are equally
"close" to infinity - they are an infinite distance away - and the
spacing of the largest model number, HUGE(x), is nothing like
infinity. If SPACING were the spacing of machine numbers, then we
would agree with Robert, but it is not.
F03/0042 passed by J3 letter ballot with no changes.
F08/0109 LOCK_TYPE and unlimited polymorphic
John Reid's yes vote comment on F08/0109:
1. Edit for [6:7+].
Apart from the reference to 4.5.1, this edit has already been
adopted in F08/124 and is scheduled for inclusion in Corr 4. I
think it is better not to have the reference because no edit is
proposed for 4.5.1. I therefore suggest deletion of this edit
from this interp.
2. Edit for [127:18-19].
This paragraph was replaced in Corr 2 (F08/042). The edit here
meets the objective of the edit in F08/042, so can be a
replacement. I think a slightly bigger edit is need for
grammatical reasons. I suggest:
[127:18-19] 6.7.1.1, p4,
Instead of the edit in Corr. 2, make this change to the
original text:
Change "If is" -> "If an ALLOCATE statement
has a SOURCE= specifier and an that is".
Result for F08/0109:
/interp accepts the suggestion to remove the [6:7+] edit from this
interp because it is in interp F08/0124 planned for Corrigendum 4.
[127] 6.7.1.1, p4, without change, reads:
"If is a coarray, shall not have a
dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a
subcomponent whose dynamic type is LOCK_TYPE."
The suggested edit in this interp is:
[127:18-19] 6.7.1.1, p4,
"If" -> "If an ALLOCATE statement has a SOURCE= specifier and an",
so p4 reads:
"If an ALLOCATE statement has a SOURCE= specifier and an
is a coarray, shall not have a
dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a
subcomponent whose dynamic type is LOCK_TYPE."
John's suggested replacement edit is [127:18-19] 6.7.1.1, p4:
Instead of the edit in Corr. 2, make this change to the original
text:
Change "If is" -> "If an ALLOCATE statement
has a SOURCE= specifier and an that is".
so p4 reads:
"If an ALLOCATE statement has a SOURCE= specifier and an
that is a coarray, shall not have a
dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a
subcomponent whose dynamic type is LOCK_TYPE."
/interp accepts John's change.
F08/0109 passed as amended by J3 letter ballot.
F08/0145 Can initial-data-target be coindexed?
Result for F08/0145:
All Yes votes, no Comments, and no No votes.
F08/0145 passed by J3 letter ballot with no changes.
F08/0147 Is generic resolution of elemental assignment done at runtime?
E-mail discussion of F08/0147 by Bill Long and Malcolm Cohen:
From: Bill Long
Sent: Wednesday, November 4, 2015 7:08 AM
To: fortran standards email list for J3
Subject: (j3.2006) Clarify F08/0147 ?
In working through the test case in Interp F08/0147, I think I
understand the change, but the words I was looking for are not part of
the answer. The test case is:
Module da_module
Type t
Real c
End Type
Interface Assignment(=)
Module Procedure edasgn
End Interface
Contains
Elemental Subroutine edasgn(a,b)
Class(t),Intent(Out) :: a
Class(t),Intent(In) :: b
a%c = -b%c
End Subroutine
End Module
Program edatest
Call test(10,10,13)
Contains
Subroutine test(n,n2,m)
Use da_module
Type(t) :: x(n),z(m)
Type(t),Allocatable :: y(:)
x%c = [ (i,i=1,n) ]
z%c = [ (i,i=1,m) ]
Allocate(y(n2),Source=t(0))
y = x ! A
Print 1,y
1 Format(*(1X,F0.1,:))
y = z ! B
Print 1,y
End Subroutine
End Program
With the change made by the edits, it appears that
1) The assignment A is defined assignment and is conforming (from
first edit).
2) The assignment B is not standard conforming, since the shapes are
not the same (from second edit).
3) Effectively, auto-reallcation on assignment will not occur if the
assignment is defined assignment and the subroutine is elemental
(since the shapes already agree).
All of which is fine with me.
====
From: j3-bounces@mailman.j3-fortran.org On Behalf Of Bill Long
Sent: Thursday, November 12, 2015 8:24 AM
To: fortran standards email list for J3
Subject: Re: (j3.2006) Clarify F08/0147 ?
On Nov 12, 2015, at 2:17 AM, Cohen Malcolm wrote:
> Hi Bill,
>
> Your understanding (1) and (2) is the same as mine. For (3), I would
> word it as "For a defined assignment statement, auto-reallocation of
> allocatables does not occur, as that is only done by an intrinsic
> assignment statement."
This occurred to me as well after sending the initial email. I agree
this is clearer and more direct.
> How about adding the following extra paragraph to the answer?
>
> "With these edits, both of the statements A and B are defined
> assignment statements. Auto-reallocation of allocatable variables
> only occurs as part of an intrinsic assignment statement, so while
> statement A is conforming (because the shapes are the same),
> statement B is not conforming (because the shapes differ)."
Yes, I think this would be helpful. An extra sentence of explanation
can be valuable to someone who goes back to look at the interp much
later, and has forgotten the discussion.
Result for F08/0147:
/interp accepts Bill and Malcolm's suggestion and adds this to the
answer of the interp {no edits are changed}:
"After the edits:
1) The assignment A is defined assignment and is conforming (from
first edit).
2) The assignment B is defined assignment but is not standard
conforming, since the shapes differ (from second edit).
3) For a defined assignment statement, auto-reallocation of
allocatables does not occur, as that is only done by an intrinsic
assignment statement."
F08/0147 passed as amended by J3 letter ballot.
F08/0148 Pointer subobject in structure constructor in pure procedure
John Reid's yes vote comment on F08/0148:
The edit makes the list item be
"(3) as the corresponding to a component, or that has a
pointer component at any level of component selection, with
the POINTER attribute in a "
I think this is grammatically incorrect. It is certainly very hard
to understand. I suggest this edit instead
[312:35 12.7p2 C1283(3)] Replace this list item by
"(3) as the corresponding to a component in a
if the component has the POINTER
attribute or has a pointer component at any level of
component selection,"
Result for F08/0148:
[312:35 12.7p2 C1283(3)], without change, currently reads:
(3) as the corresponding to a component with the POINTER
attribute in a ,
The edit in interp F08/0148 is:
[312:35 12.7p2 C1283(3)] After "component" insert ", or that has a
pointer component at any level of component selection,".
making the bullet read:
"(3) as the corresponding to a component, or that has a
pointer component at any level of component selection, with
the POINTER attribute in a "
John suggests replacing the bullet with:
"(3) as the corresponding to a component in a
if the component has the POINTER
attribute or has a pointer component at any level of
component selection,"
F03/0148 passed as amended by J3 letter ballot.
----------------------------------------------------------------------
NUMBER: F03/0042
TITLE: IEEE funny values and Standard real generic intrinsic
procedures
KEYWORDS: IEEE-754, real math library
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
Is an infinite result from an infinite argument to a real math
function exceptional (raises an exception)?
Is a NaN result from a NaN argument to a real math function
exceptional (raises an exception)?
What are the results (value and exceptions) for the following
(section 13.7.*) real math library functions [suggested results
for most are included; no exception happens unless specified]:
ABS(-0.0) returns +0.0
ABS(+/-infinity) returns +infinity
ABS(NaN) returns a NaN
ACOS(x), where |x|>1, returns a NaN and raises invalid
ACOS(NaN) returns a NaN
AINT(-0.0) returns -0.0
AINT(NaN) returns a NaN
AINT(+infinity) returns +infinity
AINT(-infinity) returns -infinity
ANINT(-0.0) returns -0.0
ANINT(NaN) returns a NaN
ANINT(+infinity) returns +infinity
ANINT(-infinity) returns -infinity
ASIN(x), where |x|>1, returns a NaN and raises invalid
ASIN(NaN) returns a NaN
ATAN(-0.0) returns -0.0
ATAN(+infinity) returns +pi/2
ATAN(-infinity) returns -pi/2
ATAN(NaN) returns a NaN
ATAN2(NaN,x) returns a NaN
ATAN2(y,NaN) returns a NaN
ATAN2(+/-0.0, -0.0) returns +/-pi (and not raise invalid)
ATAN2(+/-0.0, +0.0) returns +/-0.0 (and not raise invalid)
ATAN2(+/-0.0, x) returns +/-pi for x < 0.0
ATAN2(+/-0.0, x) returns +/-0.0 for x > 0.0
ATAN2(y, +/-0.0) returns -pi/2 for y < 0.0
(and not raise divide by zero)
ATAN2(y, +/-0.0) returns +pi/2 for y > 0.0
(and not raise divide by zero)
ATAN2(+/-y, -infinity) returns +/-pi for finite y > 0.0
ATAN2(+/-y, +infinity) returns +/-0.0 for finite y < 0.0
ATAN2(+/-infinity, x) returns +/-pi/2 for finite x
ATAN2(+/-infinity, -infinity) returns +/-3pi/4
(and not raise invalid)
ATAN2(+/-infinity, +infinity) returns +/-pi/4
(and not raise invalid)
CEILING(+/-infinity) returns +/-infinity
CEILING(-0.0) returns -0.0
CEILING(NaN) returns a NaN
COS(+/-0.0) returns 1
COS(NaN) returns a NaN
COS(+/-infinity) returns a NaN and raises invalid
COSH(+/-0.0) returns 1
COSH(NaN) returns a NaN
COSH(+/-infinity) returns a +infinity DIM(NaN,y) returns a NaN
DIM(x,NaN) returns a NaN
DIM(+/-0.0, +/-0.0) returns a +0.0
DIM(+infinity, -infinity) returns a NaN and raises invalid
DIM(+infinity, +infinity) returns +0.0
DIM(-infinity, -infinity) returns +0.0
DIM(-infinity, +infinity) returns +0.0
DPROD(NaN,y) returns a NaN
DPROD(x,NaN) returns a NaN
DPROD(+/-0.0, +/-infinity) returns a NaN and raises invalid
DPROD(+/-infinity, +/-0.0) returns a NaN and raises invalid
DPROD(+/-infinity, +/-infinity) returns an infinity with its sign
being the XOR of the arguments, and raises no exceptions.
DPROD(+/-0.0, +/-0.0) returns a zero with its sign
being the XOR of the arguments, and raises no exceptions.
EXP(NaN) returns a NaN
EXP(+/-0.0) returns 1
EXP(-infinity) returns +0.0
EXP(+infinity) returns +infinity
EXPONENT(+/-0.0) returns 0 [should be -HUGE(0)] and raises invalid
EXPONENT(NaN) returns HUGE(0) and raises invalid
EXPONENT(+/-INF) returns HUGE(0) and raises invalid
EXPONENT(denormal) returns the value as if the number were
normalized and the exponent range were unbounded
If /e/ is not representable as a default integer, invalid is raised
and sign(/e/)*HUGE(0) should be returned.
FLOOR(NaN) returns a NaN
FLOOR(-0.0) returns -0.0
FLOOR(+/-infinity) returns +/- infinity
FRACTION(-0.0) returns -0.0
FRACTION(NaN) returns a NaN
FRACTION(denormal) returns the value as if the number were
normalized and the exponent range were unbounded
FRACTION(+/-infinity) returns +/- infinity
INT(NaN) returns an unspecified value and raises invalid
INT(+/-infinity) returns an unspecified value and raises
invalid
INT(+/-large), where large cannot be represented as an integer,
returns an unspecified value and raises invalid
LOG(+/-0.0) returns -infinity and raises divide-by-zero
LOG(NaN) returns a NaN
LOG(1.0) returns +0.0
LOG(x), for x < 0, returns a NaN and raises invalid
LOB(+infinity) returns +infinity
LOG10(+/-0.0) returns -infinity and raises divide-by-zero
LOG10(NaN) returns a NaN
LOG10(1.0) returns +0.0
LOG10(x), for x < 0, returns a NaN and raises invalid
LOG10(+infinity) returns +infinity
MAX(NaN,NaN) returns a NaN
MAX(NaN,y) returns y [some say it should be NaN]
MAX(x,NaN) returns x [some say it should be NaN]
MAX(-0.0,+0.0) returns +0.0
MAX(-0.0,-0.0) returns -0.0
MAX(+infinity,y) returns +infinity
MAX(-infinity,y) returns y
MIN(NaN,NaN) returns a NaN
MIN(NaN,y) returns y [some say it should be NaN]
MIN(x,NaN) returns x [some say it should be NaN]
MIN(-0.0,+0.0) returns -0.0
MIN(-0.0,-0.0) returns -0.0
MIN(-infinity,y) returns -infinity
MIN(+infinity,y) returns y
MOD(NaN,y) returns a NaN
MOD(x,NaN) returns a NaN
MOD(+/-infinity,y) returns a NaN and raises invalid
MOD(+/-infinity,+/-infinity) returns a NaN and raises invalid
MOD(x,+/-0.0) returns a NaN and raises invalid
MOD(+/-0.0,+/-0.0) returns a NaN and raises invalid
MODULO(NaN,y) returns a NaN
MODULO(x,NaN) returns a NaN
MODULO(+/-infinity,y) returns a NaN and raises invalid
MODULO(+/-infinity,+/-infinity) returns a NaN and raises invalid
MODULO(x,+/-0.0) returns a NaN and raises invalid
MODULO(+/-0.0,+/-0.0) returns a NaN and raises invalid
NEAREST(NaN,y) returns a NaN
NEAREST(x,NaN) returns a NaN
NEAREST(x,+/-0.0) returns a NaN and raises invalid [why???]
NEAREST(+infinity,+num) returns +infinity ???
NEAREST(+infinity,-num) returns +maximum finite number
NEAREST(-infinity,+num) returns -maximum finite number
NEAREST(-infinity,-num) returns -infinity ???
NINT(NaN) returns an unspecified value and raises invalid
NINT(+/-infinity) returns an unspecified value and raises
invalid
NINT(+/-large), where large cannot be represented as an
integer, returns an unspecified value and raises invalid
RRSPACING(NaN) returns a NaN
RRSPACING(+/-infinity) returns +/-infinity
[differs from current F2003]
RRSPACING(+/-0.0) returns +0.0
RRSPACING(+/-denormal) returns ???
SCALE(NaN,y) returns a NaN
SCALE(+/-infinity,y) returns +/-infinity
SCALE(-0.0,y) returns -0.0
SET_EXPONENT(NaN,y) returns a NaN
SET_EXPONENT(+/-infinity,y) returns +/-infinity
SET_EXPONENT(-0.0,y) returns -0.0
SET_EXPONENT(denormal,y) returns ???
SIGN(NaN,y), where 0 < y, returns the same NaN,
but with the sign bit cleared.
SIGN(NaN,y), where y < 0, returns the same NaN,
but with the sign bit set.
SIN(NaN) returns a NaN
SIN(+/-infinity) returns a NaN and raises invalid
SIN(-0.0) returns -0.0
SINH(NaN) returns a NaN
SINH(+/-infinity) returns +/- infinity
SINH(-0.0) returns -0.0
SPACING(NaN) returns a NaN
SPACING(+/-infinity) returns +infinity
SPACING(-0.0) returns TINY(+0.0)
SPACING(denormal) returns TINY(+0.0) ???
SQRT(NaN) returns a NaN
SQRT(+infinity) returns +infinity
SQRT(-0.0) returns -0.0
SQRT(x), where x < 0.0, returns a NaN and raises invalid
TAN(NaN) returns a NaN
TAN(+/-infinity) returns a NaN and raises invalid
TAN(-0.0) returns -0.0
TANH(NaN) returns a NaN
TANH(+/-infinity) returns +/-1.0
TANH(-0.0) returns -0.0
13.7 [300:13-15] incorrectly requires an infinite result or a
NaN result to always signal some IEEE exception.
Consider changing [300:13] "infinite result" to "infinite result
(from finite arguments)". Reason: IEEE-754 mathematical
operations on infinity that produce an infinity are
unexceptional.
Consider changing [300:14] "NaN result" to "NaN result (from
non-NaN arguments)". Reason: IEEE-754 mathematical operations
on quiet NaN operands that produce a quiet NaN result are
unexceptional.
Consider adding to 13.7 [300:15+] something along the lines of:
"Unless specified otherwise, a math function with NaN
argument(s) shall return a NaN, which should be one of the NaN
arguments." This allows not having to specify the results for
each specific math function.
Consider adding the above suggested cases to each of the 13.7.*
functions, perhaps, with a bold face IEEE sub-heading.
ANSWER:
The erroneous text quoted from 13.7 in Fortran 2003 has been revised
in Fortran 2008, and again by Corrigendum 2 for Fortran 2008, and now
no longer conflicts with the IEEE-754 standard.
To specify the results of all the intrinsics for non-normal values is
beyond the scope of an interpretation. This could be considered for a
future revision.
EDIT:
None.
SUBMITTED BY: Fred Tydeman
HISTORY: 05-121r1 m171 F03/0042 submitted
15-248 m208 Revised answer and edits - passed by J3 meeting
16-xxx m209 Passed by J3 letter ballot 16-101
----------------------------------------------------------------------
NUMBER: F08/0109
TITLE: LOCK_TYPE and unlimited polymorphic
KEYWORD: LOCK_TYPE, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is
available.
Q1. Is allocation of X%C permitted?
TYPE t
TYPE(LOCK_TYPE),ALLOCATABLE :: c
END TYPE
TYPE(t) :: x[*],y[*]
ALLOCATE(y%c)
ALLOCATE(x%c,SOURCE=y%c)
Q2. Is allocation of C permitted?
class(*), pointer :: C
type(lock_type), intent(in) :: L[*]
allocate ( C, source=L )
Q3. Is allocation of C permitted?
class(*), pointer :: C
allocate ( LOCK_TYPE :: C )
Q4. Is pointer assignment to C permitted?
class(*), pointer :: C
type(lock_type), intent(in), target :: L[*]
c => L
Q5. Is this ALLOCATE statement conforming?
CLASS(*),ALLOCATABLE, SAVE :: C[:]
TYPE(LOCK_TYPE), SAVE :: X[*]
ALLOCATE(C,MOLD=X)
ANSWER:
A1. Allocation of X%C is not intended to be allowed. An edit is
supplied to correct the requirements on allocation of LOCK_TYPE.
A2. Allocation of C is not intended to be allowed. An edit is
supplied to correct the requirements on allocation of LOCK_TYPE.
A3. This allocation of C is permitted. It cannot violate C1302 because
that is a syntax constraint. Only things that are statically
detectable static properties of the program source text can be
syntax constraints. That means that "type" in C1302 can only mean
"declared type".
C is CLASS(*) so has no declared type and therefore cannot
violate C1302.
Edits are given to fix C1302 to say "declared type" explicitly to
avoid this confusion.
Note that it is impossible to actually use the allocated target of
C in any useful fashion; SELECT TYPE cannot access it because the
associate-name would be a named lock variable, but it is not a
coarray so that would not be allowed.
So this is permitted, but useless, and because it is useless it is
also harmless. A future revision could disallow this without the
concomitant incompatibility inconveniencing any programs.
A4. Pointer assignment to C is permitted.
As in A3, this is useless but harmless. A future revision could
disallow this without the concomitant incompatibility
inconveniencing any programs.
A5. This statement was intended to be permitted. An edit is supplied
to correct the requirements.
Note that the term "potential subobject component" is defined in interp
F08/0124 and will be in Corrigendum 4:
[6:7+] After definition 1.3.33.2 parent component, insert new term
"1.3.33.2a
potential subobject component
nonpointer component, or potential subobject component of a
nonpointer component".
EDITS:
[127:8-9] 6.7.1.1 Syntax, C642,
Change "C_PTR," to "C_PTR or"
Delete ", LOCK_TYPE ... LOCK_TYPE".
[127:9+] Insert new constraint
"C643a (R627) If SOURCE= appears, the declared type of
shall not be LOCK_TYPE or have a potential subobject
component of type LOCK_TYPE."
[127:18-19] 6.7.1.1, p4,
Instead of the edit in Corr. 2, make this change to the 10-007r1 text:
Change "If is" -> "If an ALLOCATE statement
has a SOURCE= specifier and an that is".
{There is no problem with MOLD=. "subcomponent" works ok here
because we have an object not a type.}
so p4 reads:
"If an ALLOCATE statement has a SOURCE= specifier and an
that is a coarray, shall not have a
dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a
subcomponent whose dynamic type is LOCK_TYPE."
[399:17] 13.8.2.16 LOCK_TYPE, C1302
"variable of type LOCK TYPE"
-> "variable with declared type LOCK_TYPE".
SUBMITTED BY: Van Snyder
HISTORY: 14-164 m204 F08/0109 submitted
14-164r3 m204 As amended, passed by J3 meeting
14-258 m205 Failed the J3 letter ballot #31 14-233r1
15-253 m208 Revised - passed by J3 meeting
16-xxx m209 Passed as amended by J3 letter ballot 16-101
----------------------------------------------------------------------
NUMBER: F08/0145
TITLE: Can initial-data-target be coindexed?
KEYWORDS: initialization, pointers, coarrays
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
In pointer assignment, the standard is quite clear that data-target
cannot be coindexed:
C725 (R737) A data-target shall not be a coindexed object.
And there are a couple of notes related to this:
NOTE 7.45
A data pointer and its target are always on the same image. A coarray
may be of a derived type with pointer or allocatable subcomponents. For
example, if PTR is a pointer component, Z[P]%PTR is a reference to the
target of component PTR of Z on image P. This target is on image P and
its association with Z[P]%PTR must have been established by the
execution of an ALLOCATE statement or a pointer assignment on image P.
NOTE 7.46
A pointer assignment statement is not permitted to involve a coindexed
pointer or target, see C723 and C725. This prevents a pointer
assignment statement from associating a pointer with a target on
another image. If such an association would otherwise be implied, the
association status of the pointer becomes undefined. For example, a
derived-type intrinsic assignment where the variable and expr are on
different images and the variable has an ultimate pointer component.
Fortran 2008 added the ability to specify an initial-data-target in
pointer initialization:
R505 initialization is = constant-expr
or => null-init
or => initial-data-target
R506 null-init is function-reference
C510 (R503) If => appears in initialization, the entity shall have the
POINTER attribute. If = appears in initialization, the entity shall not
have the POINTER attribute.
C511 (R503) If initial-data-target appears, object-name shall be
data-pointer-initialization compatible with it (4.5.4.6).
Initial-data-target is defined in 4.5.4.6 and the only relevant
constraint for it is:
C461 (R443) The designator shall designate a nonallocatable 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.
The definition of "data-pointer-initialization compatible" is:
"A pointer variable or component is data-pointer-initialization
compatible with a target if the pointer is type compatible with the
target, they have the same rank, all nondeferred type parameters of the
pointer have the same values as the corresponding type parameters of
the target, and the target is contiguous if the pointer has the
CONTIGUOUS attribute."
Given this, is initializing a pointer to a coindexed object permitted?
For example:
program test
integer, save, target :: C[*]
integer, pointer :: P => C[3] ! Permitted?
end
While ordinary pointer assignment to a coindexed object is prohibited
by C725, there is no corresponding constraint prohibiting such
association by way of data pointer initialization.
Note that 16.5.2.5p1(2) says that pointer-assigning to a target on a
different image causes the pointer to become undefined. Since the
initialization occurs on all images, and it's not possible to restrict
the target to only the same image, the effect would be to make a
program that does this nonconforming.
ANSWER:
No, this was not intended to be permitted. A clarifying edit is
provided.
EDITS to 10-007r1:
[70:3] 4.5.4.6
In the first sentence of C461, insert ", noncoindexed" after
"nonallocatable" so that the sentence reads:
C461 (R443) The designator shall designate a nonallocatable,
noncoindexed variable that has the TARGET and SAVE attributes and
does not have a vector subscript.
SUBMITTED BY: Steve Lionel
HISTORY: 15-216 m208 F08/0145 submitted - passed by J3 meeting
16-xxx m209 Passed by J3 letter ballot 16-101
----------------------------------------------------------------------
NUMBER: F08/0147
TITLE: Is generic resolution of elemental assignment done at runtime?
KEYWORDS: Type-bound defined assignment, Allocatable
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider
Module da_module
Type t
Real c
End Type
Interface Assignment(=)
Module Procedure edasgn
End Interface
Contains
Elemental Subroutine edasgn(a,b)
Class(t),Intent(Out) :: a
Class(t),Intent(In) :: b
a%c = -b%c
End Subroutine
End Module
Program edatest
Call test(10,10,13)
Contains
Subroutine test(n,n2,m)
Use da_module
Type(t) :: x(n),z(m)
Type(t),Allocatable :: y(:)
x%c = [ (i,i=1,n) ]
z%c = [ (i,i=1,m) ]
Allocate(y(n2),Source=t(0))
y = x ! A
Print 1,y
1 Format(*(1X,F0.1,:))
y = z ! B
Print 1,y
End Subroutine
End Program
According to 7.2.1.2 Intrinsic assignment statement, an assignment
statement is an intrinsic assignment statement if (and only if) it
is not a defined assignment statement. According to 7.2.1.4 Defined
assignment statement, a defined assignment statement needs to have a
subroutine that defines the assignment "x1 = x2". For elemental
subroutines (item (5)(b)), that is true only if
"x1 and x2 are conformable"
which when x1 and x2 are both arrays, means "has the same shape".
For the example above, in the assignment marked (A), x and y will be
conformable (as both n and n2 are equal to 10), making that a defined
assignment, thus the PRINT statement after it would print
-1.0 -2.0 -3.0 -4.0 -5.0 -6.0 -7.0 -8.0 -9.0 -10.0
while in the assignment statement marked (B), y and z will not be
conformable (n2 being 10 and m being 13), making it an intrinsic
assignment. In this case, because Y is allocatable it will be
reallocated, and so the output from the second PRINT statement would
be
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0
However, this would seem to violate the fundamental principle that
generic references are resolvable at compile time. It would also
seem to be nearly useless since if the variable is not allocatable
the shapes are required to conform anyway.
Is this feature intended to work like this?
ANSWER:
No, this was a mistake. Edits are provided to remove the runtime
generic resolution.
After the edits:
1) The assignment A is defined assignment and is conforming (from
first edit).
2) The assignment B is defined assignment but is not standard conforming,
since the shapes differ (from second edit).
3) For a defined assignment statement, auto-reallocation of
allocatables does not occur, as that is only done by an intrinsic
assignment statement.
EDITS:
[24:11+] 1.6.2 Fortran 2003 compatibility, insert new incompatibility
"Fortran 2003 interpreted assignment to an allocatable variable
from a nonconformable array as intrinsic assignment, even when an
elemental defined assignment was in scope; this part of ISO/IEC
1539 does not permit assignment from a nonconformable array in
this context.".
{The unintended extension is weird and violates our own principles,
but is not in itself contradictory or ambiguous so this is an
incompatibility.}
[157:14] 7.2.1.4 Defined assignment statement, p2, item (5)(b),
Change "$x_1$ and $x_2$ are conformable"
to "$x_2$ is scalar or has the same rank as $x_1$".
{$x_1$ is TeX for italics x subscript 1.}
[157:16] Same subclause, p3, append new sentence
"If the subroutine is elemental, $x_2$ shall have the same shape as
$x_1$."
{Retain conformability as a normal requirement instead of as a
condition.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 15-219 m208 F08/0147 submitted - passed by J3 meeting
16-xxx m209 Passed as amended by J3 letter ballot 16-101
----------------------------------------------------------------------
NUMBER: F08/0148
TITLE: Pointer subobject in structure constructor in pure procedure
KEYWORDS: pointer subobject, structure constructor, pure procedure
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the module
program P
type :: T1
integer, pointer :: P1
end type T1
type :: T2
type(t1) :: P2
end type T2
type(t1), target :: V1
allocate ( V1%p1, source = 42 )
contains
pure subroutine S ( )
type(t2) :: A
1 a = t2(v1)
a%p2%p1 = a%p2%p1 + 1
end subroutine S
end program P
Item (3) in the list in constraint C1283 in subclause 12.7 prohibits
an object that is accessed by host or use association (and other
categories) to be the in a structure constructor that
corresponds to a component that has the POINTER attribute. It is
silent concerning type constructors for types that have potential
subobject components with the POINTER attribute.
Is the statement labeled 1 permitted? If so, was that intended?
ANSWER:
The statement labeled 1 was inadvertently allowed because V1
corresponds to a component of the structure constructor for type T2
that does not have the POINTER attribute.
An edit is provided to correct this mistake.
EDIT:
[312:35 12.7p2 C1283(3)] Replace this list item by
"(3) as the corresponding to a component in a
if the component has the POINTER
attribute or has a pointer component at any level of
component selection,"
SUBMITTED BY: Van Snyder
HISTORY: 15-249 m208 F08/0148 submitted
15-249r1 m208 fix typos - passed J3 meeting
16-xxx m209 Passed as amended by J3 letter ballot 16-101
----------------------------------------------------------------------