(j3.2006) (SC22WG5.5056) WG5 ballots
John Reid
John.Reid
Sun Aug 4 15:47:50 EDT 2013
WG5,
Please may I remind you that the ballot on N1983, the second draft TS on
Additional Parallel Features in Fortran, closes at 9 a.m. (UK time) on
12 August 2013?
Meanwhile, I am now starting the ballot on the latest set of
interpretations (attached). I delayed this on purpose to avoid the two
ballots finishing at the same time. This ballot closes at 9 a.m. (UK
time) on 2 September 2013.
Best wishes,
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N1988
WG5 letter ballot 6 on Fortran 2008 interpretations
John Reid, 4 August 2013
This is the sixth WG5 vote on a set of draft interpretations for Fortran
2008. They have all been approved in a J3 letter ballot.
The rules we operate on say:
--- ---
4. The chair of J3/interp gathers all interp answers that are marked
"passed by J3 letter ballot" and forwards them to the WG5 convenor.
The WG5 convenor holds a ballot of individual members; a no vote
must be accompanied by an explanation of the changes necessary to
change the member's vote to yes. The answers that pass this ballot
become "WG5 approved".
J3/interp reserves the right to recall an interp answer for more
study even if the answer passes.
5. "WG5 approved" answers are processed into a corrigendum document by
taking the edits from the interp answers and putting them in the
format required by ISO. A WG5 vote is made on forwarding the
corrigendum to SC22.
The following Fortran 2008 interpretations are being balloted:
Yes No Number Title
--- --- F03/0030 IEEE divide by zero
--- --- F03/0047 Polymorphic arguments to intrinsic procedures
--- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR
--- --- 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/0075 Pointer function reference as variable in assignment
--- --- F08/0076 Pointer function reference in READ
Subsumed by F07/0075
--- --- F08/0083 Type parameter default expressions allow circular
dependence
--- --- F08/0084 Pointer arguments to PURE functions
--- --- 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 in N1987. Each interpretation starts
there 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 to
sc22wg5 at open-std.org
by 0900 UK time on Monday, 2 September 2013, in order to be counted.
Thanks,
John.
-------------- next part --------------
J3/13-xxx
Interps from 13-006Ar1 after m201 ready for WG5 ballot
Stan Whitlock, 30-Jun-2013
Here are 16 interps {plus 1 subsumed interp} that have passed J3
letter ballot and are awaiting WG5 ballot. Our process is to
ballot both the interp that subsumes and the interp that is subsumed.
[keep this text document to 70 characters per line]...................
Table of Contents
Part 0 contains the summary status of all of the Fortran
interpretations
Part 3 contains active F03 interpretations: F03/0001-0141
Part 4 contains active F08 interpretations: F08/0001...
======================================================================
Part 0: Summary Status of these Fortran Interpretations
======================================================================
Note N:
d == done {if S = C* | T*, then done is assumed}
* == active
Status S: Defect Type T:
P == J3 consideration in progress C == Clarification
M Passed by J3 meeting E Erratum
B Passed by J3 letter ballot I Interpretation
W Passed by WG5 ballot
X Excluded for the reasons given
C1 In F2008 Corrigendum 1
C2 In F2008 Corrigendum 2
N S T number title
- - - ------ -----
* B E F03/0030 IEEE divide by zero
* B I F03/0047 Polymorphic arguments to intrinsic
procedures
* B E F03/0053 The BIND attribute for C_PTR and C_FUNPTR
* B E F03/0064 Recursive declaration of procedure interfaces
* B E F03/0100 Error in field width for special cases of signed
INFINITY output
* B E F03/0139 Functions returning procedure pointers
------
* B E F08/0071 Vector subscript target
* B E F08/0075 Pointer function reference as variable in assignment
* X E F08/0076 Pointer function reference in READ
Subsumed by F07/0075
* B E F08/0083 Type parameter default expressions allow circular
dependence
* B E F08/0084 Pointer arguments to PURE functions
* B E F08/0085 Problems with PARAMETERs
* B E F08/0086 Implied-shape and separate PARAMETER statement
* B E F08/0087 Mixed-kind character assignment
* B E F08/0088 Can ALLOCATE with SOURCE= have side-effects in a
PURE proc?
* B E F08/0089 Variable-denoting functions change existing
semantics
* B E F08/0090 What restrictions apply to initialization and
PARAMETER?
======================================================================
Part 3: Active Fortran 2003 Interpretation Requests
======================================================================
----------------------------------------------------------------------
NUMBER: F03/0030
TITLE: IEEE divide by zero
KEYWORDS: IEEE-754, divide-by-zero
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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
13-262 m201 Passed J3 letter ballot #28 13-255r1
----------------------------------------------------------------------
NUMBER: F03/0047
TITLE: Polymorphic arguments to intrinsic procedures
KEYWORDS: polymorphism, intrinsic procedures
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
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
13-262 m201 Passed J3 letter ballot #28 13-255r1
----------------------------------------------------------------------
NUMBER: F03/0053
TITLE: The BIND attribute for C_PTR and C_FUNPTR
KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute?
This affects whether an object of one of these types is permitted
directly in COMMON. C5101 in the Fortran 2008 standard states "If a
common-block-object is of a derived type, it shall be a sequence type
or a type with the BIND attribute and it shall have no default
initialization."
2. Whether the derived types C_PTR and C_FUNPTR have the BIND
attribute affects whether they are extensible. Subclause 4.5.7.1 of
the Fortran 2008 standard states "A nonsequence derived type that does
not have the BIND attribute is an extensible type." Are these types
extensible?
3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and
C_FUNPTR are derived types with private components. Are user-defined
derived types with the BIND attribute permitted to have private
components?
ANSWER:
1. No, these types do not have the BIND attribute. 15.3.3 does not
specify that they have the BIND attribute. 15.3.4 does not require
them to have the BIND attribute in order to make them interoperable.
15.3.5 would require them to interoperate with a C struct if they had
the BIND attribute; this is absurd, since C object pointers and C
function pointers are clearly not structs.
Note that whether these types have default initialization is not
specified by the standard, so possession of BIND would not necessarily
have allowed them in COMMON anyway.
Edits are provided to correct incomplete, and thus misleading,
statements about derived types and the BIND attribute.
2. No, these types were not intended to be extensible. It was an
oversight that these types were not explicitly excluded from being
extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008
standard. An edit is provided to correct this.
3. Yes, a user-defined derived type with the BIND attribute is
permitted to have private components. This situation is the same
as for SEQUENCE types, which are similar (but not interoperable).
As with SEQUENCE types, making a component PRIVATE does prevent
access, in a conforming program, to the component by a programmer who
is sufficiently determined; however, it continues to fulfill the
software engineering role for which it was intended. Note further
that there are many other situations where two different Fortran
derived types will interoperate with the same C derived type; this is
not a defect in either standard, but simply a consequence of the two
languages having different approaches to type compatibility.
EDITS to 10-007r1:
[19:15-16] In 1.3.147.6,
replace the definition of "extensible type"
with "type that may be extended using the EXTENDS clause (4.5.7.1)".
{Repair definition of extensible type.}
[77:3] In 4.5.7.1p1,
After "A derived type" insert
", other than the type C_PTR or C_FUNPTR from the intrinsic module
ISO_C_BINDING,"
{Prohibit these types from subsequent extension.}
[431:6] In 15.3.4p1, replace entire paragraph with
"Interoperability between derived types in Fortran and struct types
in C is provided by the BIND attribute on the Fortran type."
{Reduce misleading opening blather - this is just here so we didn't
start the subclause with a bunch of constraints. Alternatively we
could move paragraph 2 (and note 15.12) to replace paragraph 1.}
[431:12+2] In 15.3.4, Note 15.11,
After "is interoperable" insert "with a C struct type".
{Correct another misleading sentence.}
[431:13-18] In 15.3.4p2,
Change all four occurrences of "Fortran derived type"
to "derived type";
change the single occurrence of "Fortran type" to "derived type".
{Remove unnecessary and confusing qualification of "derived type" with
"Fortran".}
SUBMITTED BY: John Reid
HISTORY: 05-151 m171 F03/0053 submitted - Passed by J3 meeting
05-170 m172 Passed J3 letter ballot #11
N1622 m172 Failed WG5 ballot N1629
11-217r1 m195 Revised answer for Fortran 2008 - Passed
by J3 meeting
11-241 m196 Passed as amended by J3 letter ballot
#24 11-229
12-165r2 m198 Passed by J3 letter ballot #25 12-147
12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939
12-190 m199 Revised answer/edits - passed by J3 meeting
13-237 m200 Passed as amended by J3 letter ballot
#27 13-203
----------------------------------------------------------------------
NUMBER: F03/0064
TITLE: Recursive declaration of procedure interfaces
KEYWORDS: procedure, interface
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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 <interface-name> shall not depend on any
characteristic of a procedure identified by a
<procedure-entity-name> in the <proc-decl-list> 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
13-262 m201 Passed J3 letter ballot #28 13-255r1
----------------------------------------------------------------------
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 letter ballot
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 <w> = 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 <w> 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 <w> 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 <w>
is greater than or equal to the minimum required for the form
'Infinity', the form 'Infinity' is output. If <w> is zero or <w>
is less than the minimum required for the form 'Infinity' and
greater than or equal to the minimum required for the form 'Inf',
the form 'Inf' is output. Otherwise, the field is filled with
asterisks."
[252:37] Same subclause, p8, Replace "If <w> ... askerisks." with
"If <w> is greater than zero and less than 3, the field is filled
with asterisks. If <w> 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
13-262 m201 Passed as amended by J3 letter ballot #28
13-255r1
----------------------------------------------------------------------
NUMBER: F03/0139
TITLE: Functions returning procedure pointers
KEYWORDS: procedure pointer
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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 <selector> 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 <<function>>"
"1.3.77a <<function result>>
entity that returns the value of a function".
[15:31-33] Delete term 1.3.121 <<result variable>>.
[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:17] "is a pointer" -> "is a data pointer".
[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 <expr> shall not be a function reference that
returns a procedure pointer."
[170:23+] Insert new constraint
"C804a (R805) The <expr> 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
13-262 m201 Passed as amended by J3 letter ballot #28
13-255r1
----------------------------------------------------------------------
======================================================================
Part 4: Active Fortran 2008 Interpretation Requests
======================================================================
----------------------------------------------------------------------
NUMBER: F08/0071
TITLE: Vector subscript target
KEYWORDS: Pointer assignment, Vector subscript
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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 <data-target> 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 <variable>"
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
13-262 m201 Passed J3 letter ballot #28 13-255r1
----------------------------------------------------------------------
NUMBER: F08/0075
TITLE: Pointer function reference as variable in assignment
KEYWORDS: Pointer function, assignment, defined operator
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
(1) Consider the following
module Funcs
interface operator ( .op. )
module procedure Unary, Binary
end interface
contains
function Unary ( Arg )
integer, intent(in) :: Arg
integer, pointer :: Unary
...
end function Unary
function Binary ( Arg1, Arg2 )
integer, intent(in) :: Arg1, Arg2
integer, pointer :: Binary
...
end function Binary
end module Funcs
program What
use Funcs
integer :: X, Y = 42
10 .op. x = y
end program What
Is the "10" in "10 .op. x = y" an operand, and therefore an argument of
a reference to Binary, or is .op. a reference to Unary and "10" a
statement label?
(2) Consider the following
module Funcs
interface operator ( .op. )
module procedure Unary, Binary
end interface
contains
function Unary ( Arg )
integer, intent(in) :: Arg
character(len=...), pointer :: Unary
...
end function Unary
function Binary ( Arg1, Arg2 )
integer, intent(in) :: Arg1, Arg2
character(len=...), pointer :: Binary
...
end function Binary
end module Funcs
program What
use Funcs
integer :: X = 42, Y
read (10) .op. x, y
end program What
Is "10" an <io-control-spec-list>, or is "(10) .op. x" a <format>?
Note that this program is valid Fortran 90, and "(10) .op. x" is
a <format> according to the Fortran 90 standard.
ANSWER:
It was an oversight that the programs in (1) and (2) conform to the
syntax and constraints in two different ways.
The problem stems from the over-ambitious extension of allowing
pointer function references to denote variables; this was unambiguous
for <function-reference> syntax, but is not for operator syntax.
Also, operator syntax has other restrictions on it that are intended
to prevent modification of an operand, and these are subverted if the
result is treated as a variable.
Edits are supplied to remove the treatment of pointer-valued operators
as variables.
EDITS:
[117:13] In 6.2, R602, change "<expr>" to "<function-reference>".
[117:15] In 6.2, C602,
change "<expr> ... has"
to "<function-reference> shall have".
[158:18+] In 7.2.2.2, R737, add new production
"<<or>> <expr>".
{Restore description of <data-target> to F2003 version.}
[158:20+] In 7.2.2.2, After C724, add new constraint
"C724a (R737) An <expr> shall be a reference to a function that has
a data pointer result."
{Restore F2003 constraint (more or less).}
SUBMITTED BY: Van Snyder
HISTORY: 12-149 m198 F08/0075 submitted
12-149r1 m198 Revised edit
12-149r2 m198 Clarified answer, passed J3 meeting
12-196 m199 Subsumed F08/0076 and Failed J3 letter ballot
#26, 12-184
12-197 m199 Revised answer/edits - passed by J3 meeting
13-237 m200 Passed by J3 letter ballot #27 13-203
----------------------------------------------------------------------
NUMBER: F08/0076
TITLE: Pointer function reference in READ
KEYWORDS: Pointer function reference, READ, defined operator
DEFECT TYPE: Erratum
STATUS: Subsumed by F08/0075
QUESTION:
Consider the following
module Funcs
interface operator ( .op. )
module procedure Unary, Binary
end interface
contains
function Unary ( Arg )
integer, intent(in) :: Arg
character(len=...), pointer :: Unary
...
end function Unary
function Binary ( Arg1, Arg2 )
integer, intent(in) :: Arg1, Arg2
character(len=...), pointer :: Binary
...
end function Binary
end module Funcs
program What
use Funcs
integer :: X = 42, Y
read (10) .op. x, y
end program What
Is "10" an <io-control-spec-list>, or is "(10) .op. x" a <format>?
Note that this program is valid Fortran 90, and "(10) .op. x" is
a <format> according to the Fortran 90 standard.
An edit is supplied
to remove the ambiguity in the current standard.
ANSWER:
This is another example of the same problem as F08/0075, viz syntactic
ambiguity caused by the F2008 feature "operator syntax for variable
denotation". Therefore this interpretation request is subsumed by
F08/0075.
EDITS:
See F08/0075.
SUBMITTED BY: Van Snyder
HISTORY: 12-150 m198 F08/0076 submitted
12-150r1 m198 Revised answer and edits, passed J3 meeting
12-196 m199 Subsumed by F08/0075, J3 letter ballot #26,
12-184
Result: This is another instance of the same problem (syntactic
ambiguity) caused by the same feature (operator syntax
for variable denotation) as F08/0075, so needs to be
answered together with F08/0075 => example will be added to
F08/0075, and F08/0076 is therefore subsumed by F08/0075.
12-197 m199 F08/0075 passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0083
TITLE: Type parameter default expressions allow circular dependence
KEYWORDS: type parameter expressions, circular dependence
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider
type :: T ( I, J )
integer, kind :: I = J + 1
integer, kind :: J = I + 1
end type T
type(t) :: X(1,2)
print *, x%i, x%j
end
1. Is the program standard conforming?
2. What does it print?
ANSWER:
1. The program is not conformant because the standard does not establish
an interpretation.
An edit is supplied to make it clear that the program is not comformant.
2. The standard does not establish an interpretation.
EDITS:
Replace item (9) in the list in 7.1.12p1 [12-007:152:9]:
(9) "a previously declared kind type parameter of the type being
defined,"
SUBMITTED BY: Van Snyder
HISTORY: 12-172 m199 F08/0083 submitted - passed by J3 meeting
13-237 m200 Passed by J3 letter ballot #27 13-203
----------------------------------------------------------------------
NUMBER: F08/0084
TITLE: Pointer arguments to PURE functions
KEYWORDS: PURE function, POINTER, INTENT(IN)
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the following subprogram:
Real Pure Function F( X )
Real,Pointer :: X
Real :: F
f = 1.0
x = 2.0 ! (A)
Nullify(x) ! (B)
End Function F
This subprogram does not conform to Fortran 2003, because both
statements (A) and (B) violate constraint C1272 which says
"C1272 In a pure subprogram any designator with a base object that
... is a dummy argument of a pure function ... shall not be
used ... [in] a variable definition context ...".
However, the corresponding constraint in Fortran 2008, C1283, is
missing the condition that applies the constraint to a dummy
argument of a pure function, except when it has INTENT(IN). Thus
the statements marked (A) and (B) do not violate C1283, and
therefore this subprogram appears to conform to Fortran 2008.
Was this subprogram intended to be standard-conforming?
ANSWER:
No, this subprogram was not intended to be standard-conforming.
An edit is supplied to re-insert the omitted condition.
EDIT to 10-007r1:
[312:31] In 12.7, constraint C1283, after "association",
insert ", is a dummy argument of a pure function".
SUBMITTED BY: Tobias Burnus
HISTORY: 12-174 m199 F08/0084 submitted
12-174r1 m199 Revised
12-174r2 m199 Passed by J3 meeting
13-237 m200 Passed by J3 letter ballot #27 13-203
----------------------------------------------------------------------
NUMBER: F08/0085
TITLE: Problems with PARAMETERs
KEYWORDS: PARAMETER
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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 <initialization> shall appear if the entity is a
named constant (5.3.13)."
(BTW, R503 is <entity-decl>.)
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 <initialization> 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, <initialization>
shall appear in each <entity-decl>."
{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
13-262 m201 Passed J3 letter ballot #28 13-255r1
----------------------------------------------------------------------
NUMBER: F08/0086
TITLE: Implied-shape and separate PARAMETER statement
KEYWORDS: Implied-shape, PARAMETER
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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(:size(c)) = c
End Subroutine
The <array-spec> in the type declaration statement is ambiguous; if it
is an <implied-shape-spec> then the declaration of A as an
assumed-size array is erroneous, but if it is an <assumed-size-spec>
then the declaration of C 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 "<implied-shape-spec-list>" to "<implied-shape-spec>".
{This will be the unambiguous implied-shape syntax.}
[94:10+] Insert new production
"<<or>> <implied-shape-or-assumed-size-spec>".
{This will be the otherwise-ambiguous syntax.}
[95:32] 5.3.8.5p1
Replace sentence
"An assumed-size array is declared with an <assumed-size-spec>."
with
"A dummy argument is declared to be an assumed-size array by an
<assumed-size-spec> or an <implied-shape-or-assumed-size-spec>."
{Now two ways of declaring assumed size.}
[95:33] After "<<is>>" insert "<explicit-shape-spec>,".
{The unambiguous case starts with an <explicit-shape-spec>.}
[95:37+] Insert new BNF rule and constraint
"R521a <implied-shape-or-assumed-size-spec> <<is>> [ <lower-bound> :
] *
C534a An object whose array bounds are specified by an
<implied-shape-or-assumed-size-spec> 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 ... <implied-shape-spec-list>."
with
"A named constant is declared to be an implied-shape array by an
<implied-shape-or-assumed-size-spec> or an <implied-shape-spec>."
{Now two ways of declaring implied shape.}
[96:26] R522, append ", [ [ <lower-bound> : ] * ]...".
{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 "[ <lower-bound> : ] *" now appears 4 times, it might make
sense to define a BNF term for it, e.g. <star-bounds>, 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
13-262 m201 Passed as amended by J3 letter ballot #28
13-255r1
----------------------------------------------------------------------
NUMBER: F08/0087
TITLE: Mixed-kind character assignment
KEYWORDS: Mixed kind, character assignment
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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
13-262 m201 Passed J3 letter ballot #28 13-255r1
----------------------------------------------------------------------
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 letter ballot
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 <source-expr> 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
13-262 m201 Passed J3 leter ballot #28 13-255r1
----------------------------------------------------------------------
NUMBER: F08/0089
TITLE: Variable-denoting function references change existing
semantics
KEYWORDS: Pointer function, argument, ASSOCIATE, SELECT TYPE
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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 <function-reference> 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 <selector> for an ASSOCIATE or SELECT TYPE construct that is a
<function-reference> 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 <associate-name> 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 <function-reference> 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 <function-reference> 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
13-262 m201 Passed as amended by J3 letter ballot #28
13-255r1
------------------------------------------------------------------------
NUMBER: F08/0090
TITLE: What restrictions apply to initialization and PARAMETER?
KEYWORDS: PARAMETER, initialization, conformable, type conversion
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
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 <initialization> for X is not conformable in shape.
The <initialization> 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 <initialization> 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 <initialization>
shall be the same as the rank of the entity;
- if the entity does not have implied shape, <initialization> 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
13-262 m201 Passed J3 letter ballot #28 13-255r1
------------------------------------------------------------------------
More information about the J3
mailing list