13-255
To: J3 Members
From: Stan Whitlock
Subject: J3 Fortran interp letter ballot #28 - due 19-Apr-2013
Date: 10-Mar-2013
Enclosed in the next letter ballot on Fortran interpretations.
The rules by which we operate say:
o J3 votes on the answer at a J3 meeting; a simple majority
vote marks the answer as "passed by J3 meeting".
o Between J3 meetings the chair of /interp sends a J3 letter
ballot to J3 to approve interp answers that have been "passed
by J3 meeting". The letter ballot runs for 30 days. Not
voting on three of four consecutive J3 letter ballots is
grounds to terminate J3 membership. An interp answer passes
by a 2/3rds vote; a no vote must be accompanied by an
explanation of the changes necessary to change the member's
vote to yes.
J3/interp reserves the right to recall an interp answer for
more study even if the answer passes.
12 Fortran interpretations are currently "Passed by J3 meeting" after
J3 meeting #200. This is the letter ballot phase to go from "Passed
by J3 meeting" to "Passed by J3 letter ballot".
The following Fortran interpretations are being balloted:
Yes No Number Title
--- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR
--- --- F03/0030 IEEE divide by zero
--- --- F03/0047 Polymorphic arguments to intrinsic
procedures
--- --- F03/0064 Recursive declaration of procedure interfaces
--- --- F03/0100 Error in field width for special cases of signed
INFINITY output
--- --- F03/0139 Functions returning procedure pointers
--- --- F08/0071 Vector subscript target
--- --- F08/0085 Problems with PARAMETERs
--- --- F08/0086 Implied-shape and separate PARAMETER statement
--- --- F08/0087 Mixed-kind character assignment
--- --- F08/0088 Can ALLOCATE with SOURCE= have side-effects in a
PURE proc?
--- --- F08/0089 Variable-denoting functions change existing
semantics
--- --- F08/0090 What restrictions apply to initialization and
PARAMETER?
The text of these interpretations is attached. Each interpretation
starts with a row of "-"s.
Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send only the
above text {not this entire mail message} with any comments to
j3@j3-fortran.org
by 11:59:59PM, PDT, Friday, 19-Apr-2013, in order to be counted.
Thanks /Stan
------------------------------------------------------------------------
NUMBER: F03/0030
TITLE: IEEE divide by zero
KEYWORDS: IEEE-754, divide-by-zero
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Is infinity / 0.0 a divide by zero exception?
Is NaN / 0.0 a divide by zero exception?
Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero
cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2)
those two as unexceptional.
ANSWER:
On an IEEE-conformant processor, these cases do not raise exceptions
(see clauses 6.1 and 6.2 of IEC 60559:1989).
The definitions in 14.2 were intended to describe IEC 60559:1989
exceptions with sufficient latitude to allow use on machines that do
not conform to IEC 60559:1989. However, the definition of
IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989.
Furthermore, the definition of the IEEE_OVERFLOW flag is also not
consistent with IEC 60559:1989, because this exception is not raised
for operations on infinite operands.
Additionally, if the data type is not an IEEE data type, but the
exception is supported, the circumstances under which the exception is
raised are processor dependent.
Edits are provided.
EDITS to 10-007r1:
[403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW),
Replace with
"IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction,
multiplication, division, or conversion by the intrinsic function
REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is
true for the operands of the operation or conversion, and as
determined by the processor otherwise. It occurs in an intrinsic
real exponentiation as determined by the processor. It occurs in a
complex operation, or conversion by the intrinsic function CMPLX,
if it is caused by the calculation of the real or imaginary part of
the result."
[403:10-11] Clause 14.3, first paragraph, second bullet
(IEEE_DIVIDE_BY_ZERO),
Replace with
"IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC
60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the
division, and as determined by the processor otherwise. It is
processor-dependent whether it occurs in a real exponentiation with
a negative exponent. It occurs in a complex division if it is
caused by the calculation of the real or imaginary part of the
result."
[462:24+] Clause A.2, after the fifth bullet from the end of the clause
"the extent to which a processor supports IEEE arithmetic (14)",
Insert new bullet points
"- the conditions under which IEEE_OVERFLOW is raised in a
calculation involving non-IEC 60559:1989 floating-point data;
- the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO
are raised in a floating-point exponentiation operation;
- the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a
calculation involving non-IEC 60559:1989 floating-point data;"
SUBMITTED BY: Fred Tydeman
HISTORY: 05-109 m171 F03/0030 submitted
05-109r1 m171 Revised to include IEEE_OVERFLOW,
Passed by J3 meeting
05-170 m172 Passed J3 letter ballot #11
N1622 m172 Failed WG5 ballot N1629
10-238r1 m193 Revised answer - Passed J3 meeting
11-129 m194 Passed as amended by J3 letter ballot
#22 10-254
11-006Ar1 m196 Adjust edits to reference 10-007r1
N1878 m196 Failed WG5 ballot 1 N1876
13-246 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0047
TITLE: Polymorphic arguments to intrinsic procedures
KEYWORDS: polymorphism, intrinsic procedures
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
The descriptions of the intrinsic procedures often use the term "type"
without qualification. It is unclear whether they mean "declared
type" or "dynamic type". If they mean "dynamic type", then this would
appear to allow unlimited polymorphic arguments to intrinsic
procedures like ABS and SIN. Resolution of generic intrinsic
procedures in this case would create an undue (and likely unintended)
burden on the processor, and the declared type of the result of such a
function call would be unclear as well.
Question 1:
Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED,
LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic?
Question 2:
(a) Is the ARRAY argument of the intrinsic function CSHIFT permitted
to be polymorphic?
If so:
(b) If the argument is polymorphic, is the result polymorphic? What
are the declared and dynamic types of the result?
Question 3:
(a) Are the ARRAY and BOUNDARY arguments of the intrinsic function
EOSHIFT permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, then must the other be
polymorphic?
(c) Do the requirements on their types refer to their declared types
or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic? What
are the declared and dynamic types of the result?
Question 4:
(a) Are the A and MOLD arguments of the intrinsic function
EXTENDS_TYPE_OF permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
polymorphic?
(c) Do the requirements on their types refer to their declared types
or dynamic types?
Question 5:
(a) Are the TSOURCE and FSOURCE arguments of the intrinsic function
MERGE permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
polymorphic?
(c) Do the requirements on the types of the arguments refer to their
declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
What are the declared and dynamic types of the result?
Question 6:
Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC
permitted to be polymorphic?
Question 7:
(a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK
permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
polymorphic?
(c) Do the requirements on the types of the arguments refer to their
declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
What are the declared and dynamic types of the result?
Question 8:
(a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE
permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
polymorphic?
(c) Do the requirements on the types of the arguments refer to their
declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
What are the declared and dynamic types of the result?
Question 9:
(a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS
permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
polymorphic?
(c) Do the requirements on their types refer to their declared types
or dynamic types?
Question 10:
(a) Is the SOURCE argument of the intrinsic function SPREAD permitted
to be polymorphic?
If so:
(b) If the argument is polymorphic, is the result polymorphic? What
are the declared and dynamic types of the result?
Question 11:
(a) Is the SOURCE argument of the intrinsic function TRANSFER
permitted to be polymorphic?
(b) Is the MOLD argument of the intrinsic function TRANSFER permitted
to be polymorphic?
If the answer to (b) is yes:
(c) If the MOLD argument is polymorphic, is the result polymorphic?
What are the declared and dynamic types of the result?
Question 12:
(a) Is the MATRIX argument of the intrinsic function TRANSPOSE
permitted to be polymorphic?
If so:
(b) If the argument is polymorphic, is the result polymorphic? What
are the declared and dynamic types of the result?
Question 13:
(a) Are the VECTOR and FIELD arguments of the intrinsic function
UNPACK permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
polymorphic?
(c) Do the requirements on the types of the arguments refer to their
declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
What are the declared and dynamic types of the result?
Question 14:
Are any of the other arguments of any intrinsic procedure permitted to
be polymorphic?
ANSWER:
The assertion that it is unclear whether "type" means declared, dynamic, or
both, is misguided. The general rule is that wherever it makes sense, it
means both. Where only one meaning makes sense, it means that one. Where
only one meaning is intended but it would otherwise not be clear from
context, it is qualified as "declared type" or "dynamic type".
Answer 1:
Yes.
Answer 2:
(a) Yes.
(b) Yes. "The result is of the type ... of ARRAY".
Answer 3:
(a) Yes.
(b) No.
(c) The requirements apply to both the declared type and the dynamic
type.
(d) "The type has ... the type ... of ARRAY". Therefore it is polymorphic
if ARRAY is polymorphic.
Answer 4:
(a) Yes.
(b) No.
(c) The requirements refer to the declared type; this is explicitly
stated.
Answer 5:
(a) Yes.
(b) No.
(c) The requirements refer to both the declared type and the dynamic
type. Note that this means that if only one argument is polymorphic,
it is required to have the same dynamic type as the declared type.
(d) The result characteristics are the "Same as TSOURCE", therefore it is
polymorphic if TSOURCE is polymorphic.
Answer 6:
Yes.
Answer 7:
(a) Yes.
(b) No.
(c) The requirements refer to both the declared type and the dynamic
type. Note that this means that if either ARRAY or VECTOR is not
polymorphic, the requirement for type matching means that the
dynamic type of the polymorphic argument is known.
(d) The result "has the same type" as ARRAY, and therefore is polymorphic
if ARRAY is polymorphic.
Answer 8:
(a) Yes.
(b) No.
(c) The requirements refer to both the declared type and the dynamic
type.
(d) The result "has the same type" as SOURCE, and therefore is polymorphic
if and only if SOURCE is polymorphic.
Answer 9:
(a) Yes.
(b) No.
(c) The requirements are explicitly stated to refer to the declared type.
Answer 10:
(a) Yes.
(b) Yes. "The result is ... of the same type ... as ARRAY.".
Answer 11:
(a) Yes.
(b) Yes.
(c) "The result is of the same type ... as MOLD.".
Answer 12:
(a) Yes.
(b) Yes.
Answer 13:
(a) Yes.
(b) Yes.
(c) The requirements refer to both the declared type and the dynamic
type.
(d) The result has the same type as VECTOR.
Answer 14:
Yes. For example, IMAGE_INDEX, LCOBOUND, PRESENT, STORAGE_SIZE, and
UCOBOUND.
EDITS:
None.
SUBMITTED BY: Rob James
HISTORY: 05-138 m171 F03/0047 submitted - contained the
questions/answers
05-138r1 m171 Contained the edits, passed by J3 meeting
05-170 m172 Passed J3 letter ballot #11
N1622 m172 Failed WG5 ballot N1629
13-242 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0064
TITLE: Recursive declaration of procedure interfaces
KEYWORDS: procedure, interface
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Q1. Consider the following program:
PROGRAM foo
PROCEDURE(sub) :: p
INTERFACE
SUBROUTINE sub(p2)
IMPORT p
PROCEDURE(p) :: p2
END SUBROUTINE
END INTERFACE
END PROGRAM
C1216 appears to prohibit the case of an interface name in a procedure
declaration statement being the name of something declared in a later
procedure declaration statement. But it does not appear to prohibit
the case of an interface name being the name of something declared in
a later interface body.
In the above program, the characteristics of p rely on the
characteristics of sub. The characteristics of sub, in turn, rely on
the characteristics of p.
Is this program standard-conforming?
Q2. Consider the module
MODULE m1
CONTAINS
SUBROUTINE s(p)
PROCEDURE(s) :: p
END SUBROUTINE
END MODULE
Constraint C1216 does not apply here since "s" is not declared by a
procedure declaration statement; unlike Q1, it is also not declared by
an interface body. However, the characteristics of S have not been
determined before the procedure declaration statement has been
processed, and that cannot be processed until we know what the
interface of S is.
Is this program unit standard-conforming?
Q3. Consider the module
MODULE m2
CONTAINS
SUBROUTINE s1(a)
PROCEDURE(s2) :: a
END SUBROUTINE
SUBROUTINE s2(b)
PROCEDURE(s1) :: b
END SUBROUTINE
END MODULE
The interface of A depends on the interface of S2, which depends on
the characteristics of B, which depends on the characteristics of S1,
which depends on the characteristics of A; a circular dependency.
Is this program unit standard-conforming?
Q4. Consider
MODULE m3
PROCEDURE(s),POINTER :: sptr
CONTAINS
SUBROUTINE s(p)
PROCEDURE(sptr) :: p
END SUBROUTINE
END MODULE
In the normal course of events there is no problem declaring a
procedure pointer to have the interface of a module procedure that is
defined later, and this is desirable, but in this case there seems to
be a circular dependency between the characteristics of sptr, s, and
p.
Is this program unit standard-conforming?
ANSWER:
None of the examples are standard-conforming, as the standard does not
establish an interpretation for them.
An edit is provided to clarify this.
EDIT to 10-007r1:
[288:3] 12.4.3.6p2, append new sentence
"The interface specified by shall not depend on any
characteristic of a procedure identified by a
in the of the same
procedure declaration statement."
SUBMITTED BY: Rob James
HISTORY: 05-179 m172 F03/0064 submitted
05-226 m173 Passed by J3 meeting
06-133 m175 Failed J3 letter ballot #12
09-149 m187 Passed by J3 meeting
09-187r2 m188 Failed J3 letter ballot #18 09-155
13-245 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0100
TITLE: Error in field width for special cases of signed INFINITY
output
KEYWORDS: formatted output, signed infinity
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Is there an error in the description for the output of a IEEE infinity
with a sign and a field width of 3 or 8?
Fortran 2008, 10.7.2.3.2 paragraph 7, [252:33-34], describes the
output of IEEE infinities; this specifies asterisks (field overflow) if
the field width is less than 3, and omission of "inity" if the field
width is less than 8. However, this does not take into account the
fact that there might be a plus or minus sign in the field.
The current text also fails to take into account the case of = 0,
for both Infinity and NaN values.
ANSWER:
Yes, there is an error in the special cases. Edits are provided to
correctly describe the required field widths for signed infinities.
An edit is also provided to repair the description of the output of
NaN values.
EDITS to 10-007r1:
[252:33-34] 10.7.2.3.2p7, Replace "If is ... produced." with
"The minimum field width required for output of the form 'Inf' is 3
if no sign is produced, and 4 otherwise. If is greater than
zero but less than the minimum required, the field is filled with
asterisks. The minimum field width for output of the form
'Infinity' is 8 if no sign is produced and 9 otherwise. If is
zero or is less than the minimum required but large enough to
produce the form 'Inf', the form 'Inf' is output."
[252:37] Same subclause, p8, Replace "If ... askerisks." with
"If is greater than zero and less than 3, the field is filled
with asterisks. If is zero, the output field is 'NaN'.".
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-271 m181 F03/0100 submitted
07-271r2 m181 Passed by J3 meeting
07-321 m182 Failed J3 letter ballot #14 07-279
07-340r1 m182 Passed by J3 meeting
08-133r2 m183 Passed by letter ballot #15 08-101
08-164 m184 Failed WG5 ballot #5 N1722-N1726
13-247 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0139
TITLE: Functions returning procedure pointers
KEYWORDS: procedure pointer
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
(1) Is a function permitted to return a procedure pointer?
Much of the language talks about the function result variable,
but a procedure pointer is not a variable. For example, 2.2.3
says [12:16]
"The VARIABLE that returns the value of a function is called
the RESULT VARIABLE."
(emphasis mine); which indicates that the value of a function is
returned in a variable.
(2) Where may a function reference that returns a procedure pointer
appear? In particular,
(a) as a in a SELECT TYPE or an ASSOCIATE statement;
(b) within parentheses as a primary;
(c) as the argument to an intrinsic inquiry function such as
KIND or LEN.
(3) [12:18-19] says
"a subroutine may be used to change the program state by
changing the values of any of the data objects accessible
to the subroutine".
A procedure pointer is not a data object, so is this meant to
imply that a subroutine is not permitted to change the state of a
procedure pointer? Similar text for functions appears in the same
paragraph.
ANSWER:
(1b) Yes, a function is permitted to return a procedure pointer; the
text calling this a variable is in error. Edits are supplied to
correct these mistakes.
(2b) It was intended that a function reference that returns a
procedure pointer only be permitted as an argument to the
ASSOCIATED and NULL intrinsic functions and in places where an
ordinary procedure name would be acceptable. Parentheses around
a pointer act to dereference the pointer and return a copy of the
value: this action is inapplicable to procedures. Thus the
answers to the specific sub-questions are No, No, and No again.
Clarifying edits are provided.
(3) No, this implication is not intended. A clarifying edit is
provided.
EDITS for (1b):
[10:33+] Insert new term after "1.3.77 <>"
"1.3.77a <>
entity that returns the value of a function".
[15:31-33] Delete term 1.3.121 <>.
[52:2] 4.3.1.2p2, after "function result" delete "variable".
[58:23] 4.4.3.2p5,
"result variable in the function" -> "function result".
[87:9] 5.1p2 "its result variable" -> "the function result".
[109:24] 5.5p4,
"name of the result variable of that function subprogram"
-> "result of that function".
{Function *subprogram*s do not have results, the function specified by
the FUNCTION statement does, as do the ones defined by the ENTRY
statements, but the subprogram is just syntax.}
[112:15] 5.7.1.1 C587, "result variable" -> "function result".
[114:22] 5.7.2.1 C5100, "result variable" -> "function result".
[130:26] 6.7.3.2p2, after "function result" delete "variable".
[278:11] 12.3.1 "result value"->"function result".
{Reads a bit awkwardly, but it is important to use the correct terms
and to be consistent with 12.3.3 (which does) otherwise this is
undefined meaningless blather.}
[307:5,9] 12.6.2.2p3, "result variable" -> "function result", twice.
[307:12,14,15] p4, "result variable" -> "function result", thrice.
[307:15-16] Delete "The characteristics ... variable.".
[307:18,18,20] "result variable" -> "function result", thrice.
[307:20+2] NOTE 12.41, "The ... subprogram." ->
"The function result is similar to any other entity (variable or
procedure pointer) local to the function subprogram.".
[307:20+4] "this variable" -> "this entity".
[307:20+5] "that variable" -> "that entity".
[309:23,24] 12.6.2.5p3,
"result variable name" -> "name of the function result",
twice.
[310:2] 12.6.2.6p3, after "name of its result" delete "variable".
[310:2-3] Delete "The characteristics ... the result variable.".
[310:5-6] "result variables identify the same variable"
-> "result names identify the same entity"
and delete ", although their names need not be the same".
[310:6] "scalars" -> "scalar variables".
[314:3] After "The result" delete "variable".
[433:7] "result variable is a scalar"->"result is a scalar entity".
[441:7,10] 16.3.1p4, "result variable" -> "function result", twice.
[441:18-20] 16.3.3p1, "result variable" -> "function result", thrice.
[449:3-4] 16.5.3.1p1 "result variables" ->
"function results that are variables".
[450:20] 16.5.3.4p6,
"result variables" -> "function results that are variables".
[456:11] 16.6.6p1, item (15)(e),
"the result variable of a function"
-> "a variable that is the function result of that procedure"
{Also fixes all function results becoming undefined when a single
procedure is invoked!}
EDITS for (2b).
[133:26+] Insert new constraint
"C702a (R701) The shall not be a function reference that
returns a procedure pointer."
[170:23+] Insert new constraint
"C804a (R805) The shall not be a function reference that
returns a procedure pointer."
[316:12+] 13.2.1 after p6, insert new paragraph
"An argument to an intrinsic procedure other than ASSOCIATED, NULL,
or PRESENT shall be a data object."
EDITS for (3).
[30:28] After "data objects" insert "or procedure pointers".
SUBMITTED BY: Malcolm Cohen
HISTORY: 09-295 m190 F03/0139 submitted - Passed by J3 meeting:
B answers passed
10-105 m191 Passed as amended by J3 letter ballot #20
09-307
N1816 m191 Failed WG5 ballot #7 {N1805/6} - interp
updated - see 10-135r1
13-249 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0071
TITLE: Vector subscript target
KEYWORDS: Pointer assignment, Vector subscript
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider
PROGRAM m197006
REAL,TARGET :: x(100) = [ (i,i=1,100) ]
REAL,POINTER :: p(:)
TYPE t
REAL,POINTER :: q(:)
END TYPE
TYPE(t) y
p => x ! (1)
y = t(x) ! (2)
p => x( [ 1,4,9,25 ] ) ! (3)
y = t(x( [ 1,4,9,25 ] )) ! (4)
PRINT *,y%q
END PROGRAM
The pointer assignment statement at (1) associates P with X.
The intrinsic assignment statement at (2) includes the effect of
pointer assignment of X to Y%Q, but is not a pointer assignment
statement.
The pointer assignment statement at (3) is not standard-conforming
according to 6.5.3.3.2 paragraph 2:
"An array section with a vector subscript shall not be
... the in a pointer assignment statement"
However, the intrinsic assignment statement at (4) is not subject to
this requirement as it is not a pointer assignment statement.
Note that the quoted paragraph is entirely duplicative, as in:
- the first bullet item is covered by 12.5.2.4p18,
- the second bullet item is covered by C724 in 7.2.2.2
(but C724 does not cover this case either),
- the third bullet item is covered by C901 in 9.5.1.
Editorial improvements have been made in corrigendum 1. The entire
paragraph has been rewritten.
Q1. Was the statement marked (4) intended to be allowed?
Q2. If not, was it intended to be prohibited by a constraint like
C724, or was it intended to be a simple requirement?
(Editorial note: in any case surely the requirement should appear
in the pointer assignment subclause.)
ANSWER:
A1. No, this was not intended. An edit is supplied to correct this.
A2. Constraint C724 was intended to cover this case. An edit is
supplied to correct this.
EDIT:
[158:19-20] In 7.2.2.2 Syntax of the pointer assignment statement,
C724, change ""(R737) A "
to "A variable that is a pointer target",
making the whole constraint read:
"A variable that is a pointer target shall have either the TARGET
or POINTER attribute, and shall not be an array section with a
vector subscript."
{Make the constraint apply to all forms of pointer assignment.}
{Notice that this edit incorporates the list item concerning vector
subscripts from 6.5.3.3.2p2 status quo ante corrigendum 1.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 12-121 m197 F08/0071 submitted
12-121r1 m197 Revised wording with same edits - passed
by J3 meeting
12-165r2 m198 Failed J3 letter ballot #25 12-147
13-250 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0085
TITLE: Problems with PARAMETERs
KEYWORDS: PARAMETER
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
(1) Consider the program fragment
Subroutine s
Parameter (n=1)
Integer :: x,n !(A)
Parameter (x=3)
The type declaration statement marked "!(A)", declares the
entities X and N to be of type INTEGER. Furthermore, as we see by
the immediately preceding and following PARAMETER statements, both
X and N are named constants.
Unfortunately, a constraint says
C507 (R503) "An shall appear if the entity is a
named constant (5.3.13)."
(BTW, R503 is .)
Therefore one concludes that the type declaration statement marked
"!(A)" is not conforming as it violates C507 for both X and N.
Is this statement intended to be conforming?
(2) Firstly, consider
Subroutine s2(n)
Integer,Parameter :: x(n:n+1) = [ 1,2 ]
Character(n),Parameter :: y = 'abc'
...
The type declaration statements are not conforming because
according to 5.2.2p1, X and Y are automatic data objects, and C506
says that shall not appear in that case.
Now consider
Subroutine s2b(n)
Implicit Character(n) (a-z)
Parameter (y = 'abc')
Integer :: x(n:n+1)
Parameter(x=[1,2])
This is not valid Fortran 2003, because 5.2 contains the
requirement:
"The combination of attributes that may be specified for a
particular entity is subject to the same restrictions as for
type declaration statements regardless of the method of
specification. This also applies to PROCEDURE, EXTERNAL, and
INTRINSIC statements."
This requirement does not appear in F2008. However, there is no
indication in the Introduction of this new feature.
Is this extension to Fortran 2003 deliberate?
ANSWER:
(1) Yes, the type declaration statement was intended to be allowed.
An edit is supplied to correct this mistake.
(2) No, the omission of this requirement was inadvertent. An edit
is supplied to correct this mistake.
EDITS:
[88:14] In 5.2.1, Replace constraint "C507 (503)" completely with
"C507 (R501) If the PARAMETER keyword appears,
shall appear in each ."
{Fix Q1.}
[88:14+] In 5.2.1, immediately after constraint C507, insert new
constraint:
"C507a An expression that specifies a length type parameter or
array bound of a named constant shall be a constant
expression."
{Fix Q2.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 12-189 m199 F08/0085 submitted
12-189r1 m199 Passed by J3 meeting
13-237 m200 Failed as amended by J3 letter ballot
#27 13-203
13-239 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0086
TITLE: Implied-shape and separate PARAMETER statement
KEYWORDS: Implied-shape, PARAMETER
DEFECT TYPE: Clarification or Erratum
STATUS: Passed by J3 meeting
QUESTION:
Q1. Consider
Program test1
Character(*) a,b(*)
Dimension c(*)
Parameter (a='123', b=['1','2','3'])
Character(*),Parameter :: c = [ '44','55','66' ]
Print *,a,b,c
End
The definition of the assumed-length character named constant A
conforms to Fortran 77 to Fortran 2008. However, the definition of
the implied-shape named constant B appears not to conform to Fortran
2008, as the standard says in 5.4.11p2
"A named array constant defined by a PARAMETER statement shall have
its shape specified in a prior specification statement."
On the other hand, the named constant C does not have such a
requirement, so its definition would appear to be conforming.
This apparent requirement on the named constant B would thus appear to
be inconsistent with those on the named constant C, as well as
inconsistent with the way that assumed length works, and with the
general principle of allowing attributes to be specified either in a
single type declaration statement or with separate specification
statements.
Is the program intended to conform to the Fortran standard?
Q2. Consider
Subroutine test2(a)
Real,Dimension(*) :: a,c
Parameter (c = [ 45.6 ])
a(b) = c
End Subroutine
The in the type declaration statement is ambiguous; if it
is an then the declaration of A as an
assumed-size array is erroneous, but if it is an
then the declaration of B as an implied-shape array is erroneous.
Is this program-unit intended to be standard-conforming?
ANSWER:
A1. Yes, the program was intended to conform to the Fortran standard.
An edit is provided to modify the requirement for prior
specification so as to allow this case.
A2. Yes, the program is intended to conform to the Fortran standard.
An edit is provided to add syntax to permit this unambiguously.
EDITS to 10-007r1:
[94:10] 5.3.8.1, R515,
Change "" to "".
{This will be the unambiguous implied-shape syntax.}
[94:10+] Insert new production
"<> ".
{This will be the otherwise-ambiguous syntax.}
[95:32] 5.3.8.5p1
Replace sentence
"An assumed-size array is declared with an ."
with
"A dummy argument is declared to be an assumed-size array by an
or an ."
{Now two ways of declaring assumed size.}
[95:33] After "<>" insert ",".
{The unambiguous case starts with an .}
[95:37+] Insert new BNF rule and constraint
"R521a <> [ :
] *
C534a An object whose array bounds are specified by an
shall be a dummy data
object or a named constant."
{The otherwise-ambiguous case. Note careful wording.}
[96:24-25] 5.3.8.6p1
Replace sentence
"An implied-shape array ... ."
with
"A named constant is declared to be an implied-shape array by an
or an ."
{Now two ways of declaring implied shape.}
[96:26] R522, append ", [ [ : ] * ]...".
{This is now the unambiguously implied-shape spec.}
[107:11] 5.4.11p1 "shape" -> "rank".
{In the PARAMETER statement, only require the rank to be specified in
a prior specification statement.}
NOTES ON THE EDITS:
(1) Since "[ : ] *" now appears 4 times, it might make
sense to define a BNF term for it, e.g. , and use
that term in those places instead.
(2) The current wording of C533 is slightly defective, as it does not
clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as
how that does indeed declare "the array bounds of a dummy data
object". C533 should probably be reworded similarly to C534a.
SUBMITTED BY: Bill Long
HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm
Cohen - passed by J3 meeting
13-237 m200 Failed letter ballot
13-235 m200 Revised with straw votes
13-235r1 m200 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0087
TITLE: Mixed-kind character assignment
KEYWORDS: Mixed kind, character assignment
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
For a processor that supports both ASCII and ISO 10646 UCS-4
character kinds, assuming without loss of generality that
Selected_Char_Kind('ASCII') is equal to 1 and that
Selected_Char_Kind('ISO_10646') is equal to 10646,
consider the following program:
Module charkinds
Integer,Parameter :: ascii = 1
Integer,Parameter :: ucs4 = 10646
End Module
Module overload
Use charkinds
Interface Assignment(=)
Module Procedure char_asg
End Interface
Contains
Subroutine char_asg(a,b)
Character(*,ascii),Intent(Out) :: a
Character(*,ucs4),Intent(In) :: b
Do i=1,Min(Len(a),Len(b))
a(i:i) = Achar(Mod(Iachar(b(i:i))+1,127))
End Do
a(i:) = Repeat('*',Len(a)-Len(b))
End Subroutine
End Module
Program test
Use overload
Character(10,ascii) x
x = ucs4_'Hello'
Print *,'"',x,'"'
End Program
This program conforms to Fortran 95, which permitted user-defined
assignment between all characters with different kinds.
However, Fortran 2008 provides intrinsic assignment between
ISO 10646 characters and ASCII characters, so user-defined assignment
is not permitted (12.4.3.4.3 and Table 7.8).
Thus there seems to be a contradiction between the Fortran 95
compatibility description in 1.6.3 and 12.4.3.4.3.
Is the program intended to conform to Fortran 2008?
And if it does, does it print
"Hello "
(intrinsic assignment)
"Ifmmp*****"
(user-defined assignment)?
ANSWER:
The program was not intended to conform to the standard.
An edit is provided to remove the contradiction.
EDITS:
[24:14] 1.6.3p1, "Any"
-> "Except as identified in this subclause, any".
{No longer true.}
[24:15] Split the sentence "The ..." introducing the list into a
separate paragraph (which will be the third paragraph), and
insert a new paragraph (as the second paragraph) as follows:
"Fortran 95 permitted defined assignment between character strings
of the same rank and different kinds. This part of ISO/IEC 1539
does not permit that if both of the different kinds are ASCII,
ISO 10646, or default kind."
{Describe the incompatibility.}
[25:2+] 1.6.4, after p2, insert a new paragraph.
"Fortran 90 permitted defined assignment between character strings
of the same rank and different kinds. This part of ISO/IEC 1539
does not permit that if both of the different kinds are ASCII,
ISO 10646, or default kind."
{Describe the incompatibility.}
SUBMITTED BY: Van Snyder
HISTORY: 13-204 m200 F08/0087 submitted
13-204r1 m200 Revised - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0088
TITLE: Can ALLOCATE with SOURCE= have side-effects in a PURE proc?
KEYWORDS: Allocate, SOURCE=, PURE, side-effects
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
On comp.lang.fortran Ian Harvey brought up a pointer/PURE
question.
Given a type definition like
type :: int_ptr
integer, pointer :: i
end type int_ptr
And a PURE function like
PURE function FUN (arg)
type(int_ptr), intent(in) :: arg
type(int_ptr), allocatable :: tmp
FUN = 1
allocate (tmp, source=arg)
tmp%i = 2
end function fun
Is FUN standard conforming?
Doesn't the use of source=arg allow the function to modify a global
entity via the tmp%i = ...? There don't seem to be any constraints on
what arg%i can point to, which means that the assignment to tmp%i can
have side effects.
Note that C1283(1) prevents usage like
arg%i = 2
ANSWER:
This was not intended to be standard-conforming.
An edit is supplied to remedy this oversight.
EDITS:
[312:37] Delete "or" and add a new item
"(4a) as the in a SOURCE= clause if the designator is
of a derived type that has an ultimate pointer component, or"
SUBMITTED BY: Dick Hendrickson
HISTORY: 13-226 m200 F08/0088 submitted
13-226r1 m200 Edits added - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0089
TITLE: Variable-denoting functions change existing semantics
KEYWORDS: Pointer function, argument, ASSOCIATE, SELECT TYPE
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Questions 1-3 use this module:
Module m200c2
Integer,Target :: x = 42
Contains
Function fx()
Integer,Pointer :: fx
fx => x
End Function
End Module
Q1. Consider this main program
Program q1
Use m200c2
Call test(x,fx()) ! The call.
Contains
Subroutine test(a,b)
Integer :: a,b
a = a*10 ! The assignment.
Print *,a,b
End Subroutine
End Program
According to Fortran 2003, "fx()" in the CALL statement is an
expression and not a variable, and has the value 42. It follows
that the assignment "a = a*10" is standard-conforming and does
not affect the value of B. Therefore this program prints
420 42
However, according to Fortran 2008, "fx()" in the CALL statement is a
variable, and therefore the assignment does not conform to the
standard because it affects the value of B and so violates 12.5.2.13
item (3) which requires all updates to B to go through the dummy
argument, and therefore the behaviour of the program is unspecified.
This conflicts with the statement in clause 1 that all Fortran 2003
programs remain conforming in Fortran 2008.
Is this program intended to remain standard-conforming?
Q2. Consider this main program
Program q2
Use m200c2
Call test(x,fx()) ! The call.
Contains
Subroutine test(a,b)
Integer,Target :: a,b
a = a*10 ! The assignment.
Print *,a,b
End Subroutine
End Program
According to Fortran 2003, "fx()" in the CALL statement is an
expression and not a variable, and has the value 42. It follows
that the assignment "a = a*10" is standard-conforming and does
not affect the value of B. Therefore this program prints
420 42
However, according to Fortran 2008, "fx()" in the CALL statement is a
variable, and therefore the assignment to A affects the value of B, so
the program will print
420 420
This apparently conflicts with the statement in clause 1 that Fortran
2008 is an upwards compatible extension to Fortran 2003.
Is this program intended to have altered semantics?
Q3. Consider this main program
Program q3
Use m200c2
Associate(y=>fx()) ! The association.
x = 0 ! The assignment.
Print *,x,y
End Associate
End Program
This main program apparently conforms to both Fortran 2003 and Fortran
2008, but according to Fortran 2003 "fx()" in the association is an
expression, evaluated on entry to the construct, and therefore Y
becomes associated with the value 42, and therefore the program prints
the values (spacing may differ)
0 42
whereas according to Fortran 2008 "fx()" in the association is a
variable, and every reference to Y is a reference to the associated
variable, so the assignment also changes the value of Y and therefore
the program prints the values
0 0
This apparently conflicts with the statement in clause 1 that Fortran
2008 is an upwards compatible extension to Fortran 2003.
Is this program intended to have altered semantics?
Q4. Consider this program
Module m200c2_q4
Integer,Target :: x = 42
Contains
Function fx()
Class(*),Pointer :: fx
fx => x
End Function
End Module
Program q4
Use m200c2_q4
Select Type (q=>fx())
Type Is (Integer)
x = 0
Print *,x,q
End Select
End Program
Using the same logic as Q2, this should print the values
0 42
in Fortran 2003, but the values
0 0
in Fortran 2008.
Again, this is not upwards compatible with Fortran 2003.
Is this program intended to have altered semantics.
ANSWER:
A1. This program is not intended to be conforming to Fortran 2008.
An edit is supplied to note the incompatibility between Fortran
2008 and previous Fortran standards.
A2. This program was intended to have different semantics in Fortran
2008. An edit is supplied to note the incompatibility.
A3. This program was intended to have different semantics in Fortran
2008. An edit is supplied to note the incompatibility.
A4. This program was intended to have different semantics in Fortran
2008. An edit is supplied to note the incompatibility.
EDITS to 10-007r1:
[24:11+] 1.6.2 "Fortran 2003 compatibility",
insert new paragraphs at the end of the subclause,
after the paragraphs added by Corrigendum 2:
"An actual argument that corresponds to a nonpointer dummy argument
and which is a to a pointer function is
regarded as a variable by this part of ISO/IEC 1539 but was
regarded as an expression by Fortran 2003; if the target of the
pointer result is modified other than through that dummy argument
during execution of the called procedure, and that dummy argument
does not have the POINTER or TARGET attribute, the program does not
conform to this part of ISO/IEC 1539. If that dummy argument does
have the POINTER or TARGET attribute, any further reference to that
dummy argument will have the modified value according to this part
of ISO/IEC 1539 instead of the initial value as specified by
ISO/IEC 1539-1:2004.
A for an ASSOCIATE or SELECT TYPE construct that is a
to a pointer function is regarded as a
variable by this part of ISO/IEC 1539; if the target of the pointer
result is modified during execution of the construct, any further
references to the will have the modified value
according to this part of ISO/IEC 1539 instead of the initial value
as specified by ISO/IEC 1539-1:2004."
[24:14-16] 1.6.3 "Fortran 95 compatibility", paragraph 1, sentence 2,
Change "Any" to "Except as identified in this subclause, any",
Delete "The following Fortran 95 features .. 1539."
{We are about to add a non-conformance, so the last sentence will
become wrong and it is in any case unnecessary.}
[24:17-27] Change all bullet points into separate paragraphs.
{These are no longer a list.}
[24:27+] Insert new paragraph at end of subclause
"An actual argument that corresponds to a nonpointer dummy argument
and which is a to a pointer function is
regarded as a variable by this part of ISO/IEC 1539 but was
regarded as an expression by Fortran 95; if the target of the
pointer result is modified other than through that dummy argument
during execution of the called procedure, the program does not
conform to this part of ISO/IEC 1539."
[24:30] 1.6.4 "Fortran 90 compatibility", paragraph 1
Change "Any" to "Except as identified in this subclause, any",
[25:6+] Insert new paragraph at end of subclause.
"An actual argument that corresponds to a nonpointer dummy argument
and which is a to a pointer function is
regarded as a variable by this part of ISO/IEC 1539 but was
regarded as an expression by Fortran 95; if the target of the
pointer result is modified other than through that dummy argument
during execution of the called procedure, the program does not
conform to this part of ISO/IEC 1539."
SUBMITTED BY: Malcolm Cohen
HISTORY: 13-228 m200 F08/0089 submitted
13-228r1 m200 Revised - passed by J3 meeting
------------------------------------------------------------------------
NUMBER: F08/0090
TITLE: What restrictions apply to initialization and PARAMETER?
KEYWORDS: PARAMETER, initialization, conformable, type conversion
DEFECT TYPE: Clarification or Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider the programs
Program m200c3_1
Integer :: a(10,10)
Parameter (a = [ (i,i=1,100) ] )
Print *,a
End Program
Program m200c3_2
Parameter (b = 'ok')
Print *,b
End Program
Program m200c3_3
Integer :: x(23) = [ 1 ]
Print *,x
End Program
Program m200c3_4
Integer :: y = 'ok'
Print *,y
End Program
The PARAMETER statement for the named constant A has an expression
whose shape does not conform with that of A. The PARAMETER statement
for the named constant B has an expression whose type does not conform
to that of B. The for X is not conformable in shape.
The for Y is not conformable in type.
There appears to be no requirement either for shape or type
conformance, in Fortran 2008 or in previous Fortran standards, except
for initializing data pointers.
Q1. Do any of these programs conform to Fortran 2008?
Q2. If there is meant to be a requirement for the shapes to conform or
for the types to be convertible, should this not be a constraint?
ANSWER:
A1. No, these programs do not conform to Fortran 2008, as no
interpretation is established for any of them. Edits are
provided to clarify this.
A2. This is not a constraint. A future revision of Fortran might
choose to mandate diagnosis of these errors.
EDIT to 10-007r1:
[88:30+] 5.2.1 Syntax, Insert new paragraph at end of subclause
"If appears for a nonpointer entity,
- its type and type parameters shall conform as specified for
intrinsic assignment (7.2.1.2);
- if the entity has implied shape, the rank of
shall be the same as the rank of the entity;
- if the entity does not have implied shape, shall
either be scalar or have the same shape as the entity.".
[107:12+] 5.4.11 PARAMETER statement, after p2, Insert new paragraph
"The constant expression that corresponds to a named constant shall
have type and type parameters that conform with the named constant
as specified for intrinsic assignment (7.2.1.2). If the named
constant has implied shape, the expression shall have the same rank
as the named constant; otherwise, the expression shall either be
scalar or have the same rank as the named constant.".
SUBMITTED BY: Malcolm Cohen
HISTORY: 13-229 m200 F08/0090 submitted - passed by J3 meeting
------------------------------------------------------------------------