11-129
To: J3
From: Stan Whitlock
Subject: Results of the J3 interp letter ballot #22
Date: 2011 January 27
Here are the results of J3 letter ballot #22 on Fortran
interpretations that officially closed 19-Nov-2010. The ballot is
in J3 paper 10-254 for meeting #193. If I have transcribed a vote
or a comment incorrectly, please let me know.
J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F08
030 048 085 091 096 105 110 121 123 124 128 006
Robert Corbett N Y Y Y N Y Y C C N Y Y
Bill Long C Y Y Y Y Y C Y Y Y Y Y
Jeanne Martin/Malcolm Cohen no ballot received
Dan Nagle no ballot received
Toon Moene (*) Y Y Y Y Y Y C Y Y Y Y Y
John Reid comment - - - - - - - - - - - -
Van Snyder C C Y Y C C C c C N Y Y
Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y
Jim Xia Y Y Y Y Y Y Y Y Y Y Y Y
J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08
040 041 042 043 044 045 046 047 048 049
Robert Corbett Y Y Y Y Y Y Y Y Y Y
Bill Long Y C Y Y Y Y Y Y N C
Jeanne Martin/Malcolm Cohen no ballot received
Dan Nagle no ballot received
Toon Moene (*) Y Y Y Y Y Y Y Y Y Y
John Reid comment C N - - - - - - N -
Van Snyder Y N C Y Y Y Y Y Y Y
Stan Whitlock Y Y Y Y Y Y Y Y Y Y
Jim Xia Y N Y Y Y N Y Y N Y
* Toon is a voting alternate for Craig Rasmussen
where Y means "yes"
C "yes with comment"
N "no with comment"
The comments for each interp are attached below in the same order as
the table above. The summary of DRAFT results is as follows:
F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F08 F08 F08 F08 F08 F08
030 048 085 091 096 105 110 121 123 124 128 006 040 041 042 043 044
C C Y Y C C C Y Y F Y Y C F Y Y Y
F08 F08 F08 F08 F08
045 046 047 048 049
F Y Y F Y
Y = passed
C = passed as amended
F = Failed J3 letter ballot
The interps marked "C" pass with some minor fixes, as noted below.
The edited interps in their final form are attached and will appear
in the next version 006A.
/Stan
************************************************************************
F03/0030 IEEE divide by zero
Robert Corbett's No vote on F03/0030:
The proposed edits should be rejected because they do not have the
desired meaning. The edits assume that if IEEE_SUPPORT_DATATYPE is
true for the type of the operands of a real intrinsic operation,
the operation will have the exception semantics of the corresponding
operation defined by IEC 60559:1989. That is not the case. The
definition of IEEE_SUPPORT_DATATYPE in Section 14.11.24 of 10-007
[417:8-17] might appear to specify the desired semantics.
Nonetheless, the amplified specification given in the first
paragraph of Section 14.9 [406:11-19] does not specify the desired
semantics. Even if IEEE_SUPPORT_DATATYPE is true for a given
argument, operations on real data with the same kind type parameter
value need not have the exception semantics specified by IEC
60559:1989. The first paragraph of Section 14.9 does not specify
the semantics of division, so it does not specify the exception
semantics of division as defined by IEC 60559:1989. It specifies
the semantics of addition, subtraction and multiplication only for
operands and results that are normal numbers. Because an operation
that signals an overflow or divide-by-zero exception does not
produce a normal result, real addition, subtraction and
multiplication are not required to have the exception semantics
of the corresponding operations in IEC 60559:1989.
The rules given in Clause 14 of 10-007 for determining when a real
operation is assured to have the semantics of the corresponding
operations in IEC 60559:1989 are complicated. Unless certain
unstated assumptions are made, those rules are also incomplete.
Those rules can be made rigorous, but Section 14.3 "The
exceptions" is not where it should be done. I suggest replacing
the definitions of the exceptions in Section 14.3 with proper
definitions of the exceptions. I suggest specifying when the
exceptions are signaled elsewhere.
The definitions of the exceptions given in Clause 14 of 10-007
assume that the representable real values are symmetric about zero.
While that is true for modern floating-point formats, it has not
always been so. Definitions of the overflow and underflow
exceptions that are correct for asymmetric floating-point formats
will be longer than those currently provided.
Bill Long's Comment on F03/0030:
In the History section, 10-nnn should be 10-238r1.
Van Snyder's Comment on F03/0030:
Change "not true" to "false" because "not true" includes "undefined".
This leaves the program non-conforming (presumably because the
processor is defective) if the result is undefined.
After [403:10-11] insert "14.3p1, second bullet".
After [462:24+] insert "A.2p1".
Malcolm replied to Van:
> Change "not true" to "false" because "not true" includes "undefined".
No it doesn't.
> This leaves the program non-conforming (presumably because the
> processor is defective) if the result is undefined.
Being undefined is a property of a variable. IEEE_SUPPORT_DATATYPE
is not a variable, it is a function. A function reference (other
than a pointer-valued function) returns a value of the type. That
does not include the concept of being undefined.
Van replied to Malcolm:
The "result variable" of a function is a variable. I found where the
standard requires a value to be assigned to a function's result
variable. I suspect you're right that there is not a
standard-conforming way to do that, and leave the result undefined.
Malcolm replied to Van:
> The "result variable" of a function is a variable.
However, we are talking about a function reference, not a reference
to the result variable.
According to the definition of "defined" (or indeed "undefined"), it
is a concept that applies only to a data object, that is "constant,
variable, or subobject of a constant". That is conspicuously lacking
any mention of "function reference".
And since these are supplied by the compiler (being part of an
intrinsic module), there isn't any "result variable" anyway.
> I found where the standard requires a value to be assigned to a
> function's result variable. I suspect you're right that there is
> not a standard-conforming way to do that, and leave the result
> undefined.
Not only is there no standard-conforming way, there is no way at all
since
*the result of evaluating a function reference is not a data object*
by definition.
result of ballot on F03/0030:
Only Bill's change will be made as a result of these comments =>
F03/0030 passes as amended
F03/0048 Control edit descriptors in UDDTIO
Van Snyder's Comment on F03/0048:
Change reference in the question to 9.6.4.8p26.
In edits for [227:15], replace "section 9.6.4.8, in" by "9.6.4.8p25,"
or insert ", 25th paragraph," after "9.6.4.8".
In edits for [227:17] and [227:18], replace "section 9.6.4.8"
by "9.6.4.8p26" or insert ", 26th paragraph" after "9.6.4.8".
In edits for [487:28] maybe replace "section C.6.2, first
paragraph" by "C.6.2p1".
result of ballot on F03/0048:
Van's change will be made as a result of these comments => F03/0043
passes as amended
F03/0085 Finalizing targets of pointer or allocatable actual arguments
F03/0091 Array components cannot depend on length type parameters
F03/0096 Can a read statement change the unit value?
Robert Corbett's No vote on F03/0096:
The new sentence
The value of an or of a FMT=, ID=,
IOMSG=, IOSTAT= or SIZE= specifier shall not depend on any
or .
is problematic. For example, it will be unusual for the value
assigned to a SIZE= specifier not to depend on any .
I understand that the problem exists in the current text.
I suggest splitting the specifiers into four categories, and
treating each separately. The four categories are IN-specifiers,
OUT-specifiers, IN/OUT-specifiers and run-time format expressions.
The UNIT= specifier for an internal WRITE statement is the only
IN/OUT-specifier in the current version of the language. The
OUT-specifiers should be excluded from the text given in
paragraph 5 of Section 9.12 [243:3-5]. The restrictions given
in paragraphs 7-9 of Section 9.12 together with the restrictions
on the side effects of expressions within a statement appear to
be sufficient, but I might have missed something.
Van Snyder's Comment on F03/0096:
In the ANSWER, change "n the specifier" to "in the specifier".
result of ballot on F03/0096:
Only Van's change will be made as a result of these comments =>
F03/0096 passes as amended
F03/0105 SIZE= specifier and UDDTIO
Van Snyder's Comment on F03/0105:
In the Discussion, change "9.5.1.14 [191:21-26]" to
"9.6.2.15 [216:32-36]".
Change "using list-directed" to "using a list-directed"
result of ballot on F03/0105:
Van's change will be made as a result of these comments => F03/0105
passes as amended
F03/0110 Restoring dropped restriction on ENTRY
Bill Long's Comment on F03/0110:
I assume the title should be "Restoring dropped restriction
on ENTRY " - at least that is what is in 10-248 and in 10-254 where
the full interp is included. In the ANSWER section, the reference
in 10-007 should be 310:5-8 (not 10:5-8).
Toon Moene's Comment on F03/0110:
Title is wrong, s/b: Restoring dropped restriction on ENTRY.
Van Snyder's Comment on F03/0110:
Change the title here to "Restoring dropped restriction on ENTRY"
Stan Whitlock's remark about F03/110 in 10-254:
Just FYI - Van is correct. The title of interp F03/0110 is incorrect
in the vote summary in 10-254. It should be "Restoring dropped
restriction on ENTRY" which is the title of interp F03/0110.
result of ballot on F03/00110:
The title of interp F03/0110 is "Restoring dropped restriction on
ENTRY". Bill's change will be made as a result of these comments =>
F03/0110 passes as amended
F03/0121 Precise FP semantics of the REAL intrinsic
Robert Corbett's Comment on F03/0121:
I agree with Van Snyder that users expect different semantics
from those specified in the interpretation. I understand that
the interpretation is how the members of the committee have
interpreted the standard since the FORTRAN 77 standard.
Van Snyder's Comment on F03/0121:
This question keeps coming up, and the committees keep
avoiding the most useful answer, i.e., the one the submitter
(that is, a real user with a real problem) always asks for.
Although the answer correctly interprets the standard, the
result is to force the programmer to use a mysterious kludge.
Hopefully, some future revision of the standard actually will
require REAL with a KIND argument to produce a result of the
specified kind, not one of whatever representation the
processor happens to find handy.
result of ballot on F03/0121:
No change will be made as a result of these comments => F03/0121
passes unchanged
F03/0123 Implicit typing in derived types
Robert Corbett's Comment on F03/0123:
When I began investigating the issue described in the request for
interpretation, I compiled and ran my examples using eight
different compilers. All eight compilers successfully compiled
my code. Four of the compilers moved the implicit declaration to
the enclosing scoping unit. Four of the compilers restricted the
scope of the implicit declaration to the scoping unit that is the
derived type definition.
Oracle's implementation works as specified in the interpretation,
so I voted for the interpretation. Nonetheless, I think the
interpretation misses an opportunity to improve the language.
Implicit typing should have been banned in derived type
definitions. The standard states
The data entity is treated as if it were declared in
an explicit type declaration in the outermost inclusive
scope in which it appears.
An explicit type declaration is not allow in a derived type
definition. Therefore, under a strict interpretation of the
standard, the code would be considered not to be standard
conforming.
Van Snyder's Comment on F03/0123:
Does this beg for another interpretation request with IMPLICIT NONE
in the main program?
result of ballot on F03/0123:
No change will be made as a result of these comments => F03/0123
passes unchanged
F03/0124 definition is poorly defined
Robert Corbett's No vote on F03/0124:
I agree with Malcolm Cohen that the new text is a big improvement
over the existing text. However, I also take Van Snyder's point
that there is further room for improvement. I think with a bit
more work in Section 16.6 of 10-007, an interpretation that covers
all the cases that should be allowed could be achieved.
Van Snyder's No vote on F03/0124:
The answer implied by the edits is too restrictive. It should
be something like
"When a component of a structure of numeric sequence type or
character sequence type becomes defined as a result of
partially associated objects becoming defined, associated
components of the same type that are components of an object
of different type do not become undefined." (This is ugly and
will need some polishing, but you get the idea.)
Malcolm replied to Van:
The answer is less restrictive than the text currently in the
standard, in that it adds another exception to the blanket
requirement.
It would help if you supplied an example you think remains
non-conforming after this change but that you think should be
conforming. Reading your proposed replacement text I am at a loss
to see how the effect of it differs from that in the interp.
(If there is a difference, I'm sure I could work it out
eventually, but you must have something in mind already, right?)
Van replied to Malcolm:
I had in mind the case of common block declarations resulting in
partial and overlapping storage associations of numeric sequence
type objects in such a way that their ultimate storage-associated
components have the same types and kinds. That is, defining any
component wouldn't undefine anything.
Suppose for example that in one scoping unit there is a common
block with two numeric sequence type objects, each having two
default integer components. In another there is the same common
block with a default integer, a sequence type object with two
default integer components, and another default integer.
Assigning to any of the numeric sequence objects shouldn't
undefine anything.
result of ballot on F03/0124:
/interp will take this back for more work to solve the
closely-related problem raised by Van. We probably will be
editing the same text to solve Van's extra problem => F03/0124
fails.
F03/0128 Subobjects in namelist output
F08/0006 generic resolution with banned argument combinations
F08/0040 MOVE_ALLOC for coarrays
John Reid's Comment on F08/0040:
The edit that I suggested in 10-200 was
[372] In 13.7.118 MOVE_ALLOC (FROM, TO), paragraph 3.
In line 1, after "It shall be allocatable." add
"It shall not be a coarray."
In line 2, after "It shall be allocatable." add
"It shall not be a coarray."
This was carefully worded to be suitable for a future corrigendum,
except for "[372]" which can be removed. I think the replacement
In 13.7.118 MOVE_ALLOC (FROM, TO), paragraph 3:
[372:18] After "It shall be allocatable." add
"It shall not be a coarray."
[372:19] After "It shall be allocatable." add
"It shall not be a coarray."
is less satisfactory since it relies on line numbers in the J3
document.
result of ballot on F08/0040:
006 is a J3 document and it uses line numbers. We have started
adding section and paragraph indications to make WG5 corrigenda
easier to construct. Improvements are made to the edit wording
as a result of these comments => F08/0006 passes as amended
F08/0041 Segment ordering rules
Bill Long's Comment on F08/0041:
In PROGRAM example1, the declaration of the p component of
type t2 should be TYPE(t1),POINTER :: P, and not TYPE(T2)... I
suspect this is just a typo. The current version results in
errors later (y%p => x has mismatched types.)
John Reid's NO vote on F08/0041:
There are errors in both examples. In example (1), the component
of type t2 should have type t1. In example (2), the PRINT
statement should reference x on another image, e.g.
PRINT *, x(1)[2].
More seriously, the edit proposed in 10-201 has been removed.
While it is not necessary for allocation, it is needed for
pointer association. This means that it is desirable to
rewrite the questions and answers. Here is my suggestion
QUESTION:
(1) If a variable is already defined (initially or by some
segment that precedes all other segments in this question),
may one image reference it while another image causes it to
become undefined in nordered segments?
For example, is
PROGRAM example2
REAL :: x(100)[*]
x = 1
SYNC ALL
IF (THIS_IMAGE()==1) THEN
PRINT *,x(1)[2]
ELSE
CALL destroy(x)
END IF
CONTAINS
SUBROUTINE destroy(x)
REAL,INTENT(OUT) :: x(:)
END SUBROUTINE
END PROGRAM
standard-conforming? This does not appear to violate any of
the segment ordering requirements in 8.5.2 because it is not
defined in any unordered segment (so bullet 1 does not apply),
there is no allocation or pointer association status (so bullet 2
does not apply), and there is no dummy argument being defined
(so bullet 3 does not apply).
(2) Was it intended to allow a pointer assignment to a pointer
that is not a subobject of a coarray to be unordered with
respect to its definition by another image through a pointer
component of a coarray?
For example,
PROGRAM example1
TYPE t
REAL,POINTER :: p
END TYPE
REAL,TARGET :: a=0.0, b=1.0
TYPE(t) :: y[*]
y%p => a ! y[n]%p => a for all n.
SYNC ALL
IF (THIS_IMAGE()==1) THEN
y%p => b ! y[1]%p => b
ELSE
y[1]%p = 999 ! Defines a[1] or b[1]?
END IF
END PROGRAM
ANSWER:
(1) No. This case has been overlooked in the segment ordering rules.
An edit is supplied to correct this.
(2) No. This case, too, has been overlooked in the segment ordering
rules. An edit is supplied to correct this.
EDITS to 10-007:
[189:14] In 8.5.2 paragraph 3, first bullet point,
After "if a variable is defined"
Insert "or becomes undefined"
(before "on an image in a segment").
[189] In 8.5.2 Segments, paragraph 3, replace the second bullet item
by
"if the allocation or the pointer association status of a variable
is changed on an image in a segment, that variable shall not be
referenced or defined in a segment on another image unless the
segments are ordered, and".
Van Snyder's No vote on F08/0041:
"is defined" is a static concept. The requirement should
always have been "becomes defined". Therefore the edit should
be to replace "variable is defined" to "variable becomes
defined or undefined" -- or do we need another interp to
repair this?
Jim Xia's No vote on F08/0041:
The first example should be fixed to have t2 contains a pointer
component of type t1. The second example is perfectly legal.
Seems we need to rework on this interp.
result of ballot on F08/0041:
In example (1), the component of type t2 is changed to type t1.
However, more work is needed on this interp as a result of these
comments => F08/0041 fails.
The edit in 10-201 referred to above is:
[189] In 8.5.2 Segments, paragraph 3, replace the second bullet
item by
"if the allocation or the pointer association status of a
variable is changed on an image in a segment, that variable
shall not be referenced or defined in a segment on another
image unless the segments are ordered, and"
F08/0042 SOURCE= questions
Van Snyder's Comment on F08/0042:
To avoid future questions of the type "how many times is ...
evaluated?" can we specify that the values of specifiers are
considered to be actual arguments to subroutines, so that the
execution semantics of CALL statements, i.e., the actual
arguments are evaluated before the invocation, apply
everywhere?
result of ballot on F08/0042:
No change will be made as a result of these comments => F08/0042
passes unchanged
F08/0043 Executing a type-bound procedure on a coindexed object
F08/0044 Resolving the type of a coarray or coindexed object
F08/0045 constraints on entities of type LOCK_TYPE
Jim Xia's No vote on F08/0045:
The edits makes it illegal to specify LOCK_TYPE as if the
coarray itself is of LOCK_TYPE. For example,
type(lock_type), allocatable :: locks[*]
The edits make the following allocate statement illegal
ALLOCATE (LOCK_TYPE: locks[*])
result of ballot on F08/0045:
/interp will take this back for more work since we think that Jim has
a valid complaint => F08/0045 fails
Perhaps the edit should be changed to
[127:7] In C641,
After "C_PTR" replace "or" by ",";
After "C_FUNPTR" insert
", or a type with a direct component of type LOCK_TYPE
(13.8.2.16) that is not a direct component of the declared
type of any ,".
[127:7+] Insert new constraint
"C641a (R626) If an is unlimited polymorphic,
shall not specify the type LOCK_TYPE
(13.8.2.16)."
F08/0046 VALUE attribute restrictions
F08/0047 public generic with same name as private type
F08/0048 Sequence association for coarrays
Bill Long's No vote on F08/0048:
The proposed restriction on coarrays as actual arguments
sequence associated with a contiguous dummy makes yet another
exception to ordinary array behavior for coarrays. In this case,
there seems to be no justification other than the view that sequence
association of arguments is archaic. I think that the confusion
introduced by making another case where coarrays are different from
ordinary arrays is less desirable that allowing coarrays to behave
like "old" arrays.
John Reid's NO vote on F08/0048:
Sequence association is allowed for array coarrays, so I can see no
reason for disallowing it for a scalar coarray that is an element of
a simply contiguous array.
12.5.2.4 para 13 says: "If the actual argument is a noncoindexed
scalar, the corresponding dummy argument shall be scalar unless the
actual argument is default character, of type character with the C
character kind (15.2.2), or is an element or substring of an element
of an array that is not an assumed-shape, pointer, or polymorphic
array."
As the standard stands, I believe that this applies. It is made not
to apply by the new edit: "If the dummy argument is a coarray that
is an array, the actual argument shall be an array."
I think this is a technical change that contradicts one of our design
principles: wherever possible, coarrays should behave just like
variables that are not coarrays.
I suggest that we go back to 10-226 which contains the edit
In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2
[297:9], add "or an element of a simply contiguous array".
Jim Xia's No vote on F08/0048:
I believe this restriction might be a bit surprising to users who
regularly use sequence associations. Also there isn't an apparent
technical difficulties in support this.
result of ballot on F08/0048:
More work is needed on this interp as a result of these comments =>
F08/0048 fails.
F08/0049 ELEMENTAL functions with nonconstant type parameters
Bill Long's Comment on F08/0049:
In the example code, the function gcd(..) is type REAL, but
a reference to it is used later to be the len parameter value in a
character(gcd(..)) declaration. The function gcd should be modified
to return an integer result. If there is interest, this is an
executable version of the test case:
MODULE ex1
INTEGER :: mylen
CONTAINS
ELEMENTAL CHARACTER(mylen) FUNCTION f(a)
INTEGER,INTENT(IN) :: a
f = REPEAT(CHAR(a),mylen)
END FUNCTION
END MODULE
ELEMENTAL FUNCTION ex2(a,b)
CHARACTER(*),INTENT(IN) :: a,b
CHARACTER(LEN(a)+LEN(b)) :: ex2
ex2 = a//b
END FUNCTION
MODULE ex3
INTEGER,ALLOCATABLE :: x(:)
CONTAINS
PURE FUNCTION gcd(a)
INTEGER,INTENT(IN) :: a(:)
integer :: gcd
gcd = sum(a)
END FUNCTION
ELEMENTAL FUNCTION f(y,z)
CHARACTER(*),INTENT(IN) :: y,z
CHARACTER(gcd([x,LEN(y),LEN(z)])) :: f
f = "1234567890"
END FUNCTION
END MODULE
program test
call test1
call test2
end program test
subroutine test1
use ex1
mylen=10
print *, f(ichar("x"))
end subroutine test1
subroutine test2
use ex3
allocate(x(3))
x = [1,1,1]
print *, f("11","222")
end subroutine test2
with output:
> ./a.out
xxxxxxxxxx
12345678
result of ballot on F08/0049:
Only Bill's change to declare gcd a INTEGER will be made as a result
of these comments => F08/0006 passes as amended
----------------------------------------------------------------------
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:
Page and line numbers refer to 10-007.
[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 result of the operation or conversion, and as
determined by the processor if IEEE_SUPPORT_DATATYPE for the result
is not true. 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] 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 result of the
division, and as determined by the processor if
IEEE_SUPPORT_DATATYPE for the result is not true. 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+] 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-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------
NUMBER: F03/0048
TITLE: Control edit descriptors in UDDTIO
KEYWORDS: Control edit descriptor
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the following program:
MODULE m
TYPE t
INTEGER :: i = 0
CONTAINS
PROCEDURE, PRIVATE :: pwf
GENERIC :: WRITE(FORMATTED) => pwf
END TYPE
CONTAINS
RECURSIVE SUBROUTINE pwf(dtv, unit, iotype, vlist, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: vlist(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(LEN=*), INTENT(INOUT) :: iomsg
WRITE(unit, '(i1, /)') dtv%i
WRITE(unit, '(t1, a2)') 'AB'
END SUBROUTINE pwf
END MODULE
PROGRAM foo
USE m
IMPLICIT NONE
TYPE(t) :: a
a%i = 3
PRINT *, 'xyz', a
end program
9.6.4.8p26 [227:17] states
A record positioning edit descriptor, such as TL and TR, used on
unit by a child data transfer statement shall not cause the record
position to be positioned before the record position at the time the
user-defined derived-type input/output procedure was invoked.
The term "record position" is used, but it doesn't appear to be
defined anywhere. Depending on the interpretation, the above program
might be standard-conforming, or it might not be.
If "record position" is taken to mean "the position within the current
record", regardless of which record is the current record, then the
record position at the beginning of the UDDTIO procedure is before the
fourth character of the record. The first child data transfer
statement begins a new record, and the second child data transfer
statement writes to the first character of the new record. This would
be before the "record position" at the time the UDDTIO procedure was
invoked, and the program would not be standard-conforming.
If "record position" is taken to mean a combination of the record and
the position within that record (essentially making it mean the same
thing as "file position"), then the above program is standard-
conforming, since the control edit descriptor doesn't cause the file
to be positioned before the record position when the UDDTIO procedure
was invoked.
What is the meaning of "record position", and is the above program
standard-conforming?
ANSWER:
The term "record position" is not well defined.
The intent of 9.6.4.8 was to prohibit a child data transfer statement
from possibility overwriting or re-reading any characters in the current
record that an active parent I/O statement had previously written or read.
9.6.4.8 should have used the term "file position" instead of
"record position".
Therefore, the program is standard-conforming, and prints
xyz.3
AB
where the first record starts with a space and the "." represents a
value separator.
Edits are supplied to clarify the intent of 9.6.4.8 and remove the phrases
"record position" and "record positioning" from the standard.
EDITS: In 10-007
[227:15] In section 9.6.4.8p25, in the paragraph that begins with
"Because a child data transfer statement does not position the
file prior to data transfer,"
replace
"effective item or record positioning edit descriptor"
with
"effective item or edit descriptor"
[227:17] In section 9.6.4.8p26, replace the phrase
"A record positioning edit descriptor, such as TL and TR,"
with
"The edit descriptors T and TL"
[227:18] Change "record position" to "file position" twice.
[487:28] In section C.6.2p1, delete "record positioning"
SUBMITTED BY: Rob James
HISTORY: 05-139 m171 F03/0048 submitted
05-139r1 m171 Passed by J3 meeting
05-170 m172 Failed J3 letter ballot #11 05-167
06-366r2 m178 Passed by J3 meeting
07-272 m181 Failed J3 letter ballot #13 07-250r1
10-241 m193 Draft answer for F2008
10-241r1 m193 Passed by J3 meeting
11-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------
NUMBER: F03/0085
TITLE: Finalizing targets of pointer or allocatable actual arguments
KEYWORDS: Finalization, pointer actual argument, allocatable actual
argument
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the program
program Finalize
type :: T
...
contains
final :: ...
end type T
type(t), pointer :: TV
allocate ( TV )
call sub ( TV )
contains
sub ( A )
type(t), intent(out) :: A
end sub A
end program Finalize
The eighth paragraph of 10-007, section 4.5.6.3 [76:30-31], says
"When a procedure is invoked, a nonpointer, nonallocatable object that
is an actual argument corresponding to an INTENT(OUT) dummy argument
is finalized.''
Q1. Is the target of TV finalized when SUB is invoked?
Q2. If TV were allocatable instead of a pointer, would it be finalized?
ANSWER:
A1. Yes
A2. Yes
It was intended that an allocatable actual argument or the target of a
pointer actual argument that is associated with an INTENT(OUT) dummy
argument be finalized when the procedure is invoked. Edits are provided
to correct the error.
EDITS: In 10-007
Replace the eighth paragraph of 4.5.6.3 [76:30-31] with:
"When a procedure is invoked, an object that becomes argument associated
with a nonpointer, nonallocatable INTENT(OUT) dummy argument of that
procedure is finalized."
SUBMITTED BY: Van Snyder
HISTORY: 06-374 m178 F03/0085 submitted
10-242 m193 Draft answer for F2008 - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F03/0091
TITLE: Array components cannot depend on length type parameters
KEYWORDS: length parameter, specification expression, component
declarations
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
Consider
MODULE m
TYPE t(n)
INTEGER,LEN :: n
REAL v(n)
END TYPE
END
Is the example intended to be standard-conforming?
ANSWER:
Yes, the example is standard-conforming in F2008.
C531 in section 5.3.8.2 [94:15-16] of 10-007 says:
"C531 (R516) An explicit-shape-spec whose bounds are not constant
expressions shall appear only in a subprogram, derived type
definition, BLOCK construct, or interface body."
EDITS:
None
SUBMITTED BY: Van Snyder
HISTORY: 07-232 m180 F03/0091 submitted (modified by M. Cohen)
10-243 m193 Draft answer for F2008 - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F03/0096
TITLE: Can a read statement change the unit value?
KEYWORDS: Read statement, unit value
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Is it allowed to change the value of a variable which supplies the
unit number to an read statement?
10-007 [243:3-5] says the value of any input/output specifier shall not
depend on any input-item. UNIT= is a specifier in a READ statement.
Note 9.40 on page 221 gives the example
READ(N) N, X(N)
and discusses how the changes to N work.
ANSWER:
Yes, the example was intended to be allowed as long as N is not an
internal unit. Edits will limit the restriction to "output items"
in the specifier list and the Format.
EDITS: In 10-007
In 9.12, paragraph 5,
[243:3-4]
Delete "on any , , or",
Making that sentence read:
"The value of a specifier in an input/output statement shall not
depend on the definition or evaluation of any other specifier in
the or in that
statement."
[243:5] Append new sentence to paragraph
"The value of an or of a FMT=, ID=, IOMSG=,
IOSTAT= or SIZE= specifier shall not depend on any or
."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-266 m181 F03/0096 submitted
07-266r1 m181 Draft answer - withdrawn, no reason, no vote
10-246 m193 Draft answer for F2008
10-246r1 m193 Revised edit - Passed by J3 meeting
11-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------
NUMBER: F03/0105
TITLE: SIZE= specifier and UDDTIO
KEYWORDS: SIZE=, UDDTIO
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
DISCUSSION:
9.6.2.15p1 [216:32-36] says that when SIZE= specifier is used in a
formatted input statement with explicit format specifications, the
variable specified in the SIZE= specifier is determined by the data
edit descriptors during the input statement. These rules, however,
did not take into account the following situation where a parent READ
statement with a DT edit descriptor invokes a user-defined DTIO
formatted read subroutine that reads input data using a list-directed or
namelist READ statement.
Consider the following example:
module example
type A
integer x(10)
contains
procedure :: readArray
generic :: read(formatted) => readArray
end type
contains
subroutine readArray (dtv, unit, iotype, v_list, iostat, iomsg)
class(A), intent(inout) :: dtv
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
read (unit, fmt=*, iostat=iostat, iomsg=iomsg) dtv%x
end subroutine
end module
program test
use example
type(A) :: v
integer countChar
open (1, file='example.input', form='formatted')
read (1, fmt='(DT)', advance='no', size=countChar) v
end program test
Note that there is no data edit descriptor in the UDDTIO subroutine,
readArray, to count the total number of characters transferred during
the child read.
QUESTION:
Is this example intended to be standard conforming?
ANSWER:
Yes, the example is standard-conforming. The definition of SIZE= in
[10-007 216:31] section 9.6.2.15 does not restrict SIZE= if a child
I/O is present. The description of how SIZE= works in [219:25]
section 9.6.4.1p22 item (9) clearly indicates that SIZE= should be
set even if child I/O occurs (items (5) and (6)).
EDITS:
None
SUBMITTED BY: Jim Xia
HISTORY: 07-302 m182 F03/0105 submitted
07-302r1 m182 Passed by J3 meeting
08-133r2 m183 Failed J3 letter ballot #15 08-101
10-247 m193 Draft answer for F2008 - Passed by J3 meeting
11-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------
NUMBER: F03/0110
TITLE: Restoring dropped restriction on ENTRY
KEYWORDS: ENTRY
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
It appears that a hard restriction found in ANSI X3.9-1978
was dropped when we published Fortran 90. The restriction
on page 15-13 of the FORTRAN 77 standard says
>In a function subprogram, a variable name that is the same
>as an entry name must not appear in any statement that
>precedes the appearance of the entry name in an ENTRY
>statement, except in a type-statement.
so
FUNCTION S()
T = 13.0
ENTRY T()
END
is not standard-conforming.
The restriction appears to be missing from Fortran 90, 95,
2003. Should it still be in force ?
ANSWER:
No, for whatever reason, the restriction was dropped a long time ago
and is not in F2008. The above program does not violate the standard
with the placement of the assignment to T. [10-007 310:5-8] Section
12.6.2.6 specifies that the results S and T in the above example share
the same memory so S() returns 13.0. As is, the example is not standard-
conforming since no return value is set for T().
EDITS:
None
SUBMITTED BY: Michael Ingrassia
HISTORY: 07-341 m182 F03/0110 submitted
10-248 m193 Draft answer for F2008 - Passed by J3 meeting
11-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------
NUMBER: F03/0121
TITLE: Precise FP semantics of the REAL intrinsic
KEYWORDS: REAL intrinsic
DEFECT TYPE: Clarification
STATUS: Passed by J3 letter ballot
QUESTION:
Must the intrinsic function REAL with KIND parameter wp return a value
that is a REAL (KIND=wp) floating point number?
RATIONALE FOR THE QUESTION:
Computer hardware may use a wider floating-point format for registers
than for memory; e.g., 80 bits for registers and 64 bits for memory
for the case of standard double precision floating point numbers.
Some algorithms require a high level of control over floating point
semantics. If the intrinsic function REAL with KIND parameter wp is
guaranteed to return a REAL (KIND=wp) result then a programmer can use
this to force intermediate results into main memory format, never mind
that the optimizing compiler may have placed the intermediate in a
register.
I am interested in a J3 interpretation of this matter, especially a
loud and clear affirmative interpretation, because it appears that
some present Fortran compilers optimize away my explicit use of the
REAL intrinsic. The context is code for compensated summation (Kahan
summation). I appreciate that parentheses are inviolable courtesy of
the Fortran standard, but in order to have code that cannot be broken
by an optimizing compiler I seem to need also a language mechanism to
force intermediate results into main memory format.
Bas Braams
Chemistry Department and
Emerson Center for Scientific Computation
Emory University
Atlanta, GA
ANSWER:
Yes, the result of the intrinsic function REAL with KIND argument wp
returns a value that is of type REAL(KIND=wp). However, the
description of REAL says that in this case
"the result is equal to a processor-dependent approximation to A".
Furthermore, if it is used within an expression involving intrinsic
operations,
"the processor may evaluate any mathematically equivalent
expression, provided that the integrity of parentheses is not
violated."
and
"mathematically equivalent expressions of numeric type may produce
different computational results",
which means that it is unlikely to serve your purpose.
Intermediate results can be rounded to storage format by using
assignment to a VOLATILE variable.
EDIT:
None.
HISTORY: 08-208r1 m185 F03/0121 submitted
10-240 m193 Draft answer for F2008 - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F03/0123
TITLE: Implicit typing in derived types
KEYWORDS: Derived types, implicit typing
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the program
PROGRAM MAIN
TYPE T
INTEGER :: I = BIT_SIZE(J)
END TYPE
! J = 0
CALL SUBR1
CONTAINS
SUBROUTINE SUBR1
J = 1
CALL SUBR2
PRINT *, J
END SUBROUTINE
SUBROUTINE SUBR2
J = 2
END SUBROUTINE
END
Q1. Is this program standard-conforming?
(In particular, is it permitted to have the first, or only,
appearance of a local variable name appear within a type
definition. The definition of implicit typing says that
J is explicitly declared within T.)
Q2. (a) If not, is it standard-conforming if the comment "! J = 0" is
turned into the assignment statement "J = 0"?
(b) If it is standard-conforming, what does it print?
(If J is a local variable of MAIN, it should print 2.)
ANSWER:
A1. Yes, the program is standard-conforming. The definition of
implicit typing is erroneous - J is a local entity of MAIN.
An edit is supplied to correct this error.
A2. (a) Not applicable.
(b) The program will print the value 2.
EDITS to 10-007:
[109:22-23] In 5.5p4,
After
"The data entity is treated as if it were declared in an explicit
type declaration"
replace "in" with "; if",
then after "the outermost inclusive scope in which it appears"
insert
"is not a type definition, it is declared in that scope, otherwise
it is declared in the host of that scope".
Note: This makes the whole sentence read
"The data entity is treated as if it were declared in an explicit
type declaration; if the outermost inclusive scope in which it
appears is not a type definition, it is declared in that scope,
otherwise it is declared in the host of that scope".
SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle)
HISTORY: 08-268 m185 F03/0123 submitted
10-244 m193 Revised answer - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F03/0124
TITLE: definition is poorly defined
KEYWORDS: definition
DEFECT TYPE: Interpretation
STATUS: J3 consideration in progress
QUESTION:
Consider the program:
PROGRAM MAIN
TYPE T1
SEQUENCE
INTEGER I, J
END TYPE
TYPE T2
SEQUENCE
INTEGER I, J
END TYPE
TYPE(T1) X
TYPE(T2) Y
EQUIVALENCE (X, Y)
X%I = 1
X%J = 2
PRINT *, X, Y
END
Is this program standard-conforming, and if so, what does it print?
According to items (1) and (12) of 16.6.5, the assignment to X%I
causes both X%I and Y%I to become defined.
Similarly, the assignment to X%J causes both X%J and Y%J to become
defined.
Then, according to item (15) of 16.6.5, both X and Y become defined.
However, according to 4.5.2.4, X and Y are types with different names,
and therefore are of different type, thus according to 16.6.6 item (1)
when X becomes defined Y becomes undefined, and vice versa. This
appears to be a contradiction.
ANSWER:
The program was intended to be standard-conforming.
An edit is supplied to remove the apparent contradiction.
The program should print something like " 1 2 1 2".
EDITS:
[455:14+] In 16.6.6 item (1), insert new sub-list item
"(c) When all components of a structure of a numeric sequence type
or character sequence type become defined as a result of
partially associated objects becoming defined, an associated
variable of a different type does not become undefined."
SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle)
HISTORY: 08-269 m185 F03/0124 submitted
10-245 m193 Draft answer - Passed by J3 meeting
11-xxx m194 Failed J3 letter ballot #22 10-254
** start negative comments
Robert Corbett's No vote on F03/0124:
I agree with Malcolm Cohen that the new text is a big improvement
over the existing text. However, I also take Van Snyder's point
that there is further room for improvement. I think with a bit
more work in Section 16.6 of 10-007, an interpretation that covers
all the cases that should be allowed could be achieved.
Van Snyder's No vote on F03/0124:
The answer implied by the edits is too restrictive. It should
be something like
"When a component of a structure of numeric sequence type or
character sequence type becomes defined as a result of
partially associated objects becoming defined, associated
components of the same type that are components of an object
of different type do not become undefined." (This is ugly and
will need some polishing, but you get the idea.)
Malcolm replied to Van:
The answer is less restrictive than the text currently in the
standard, in that it adds another exception to the blanket requirement.
It would help if you supplied an example you think remains
non-conforming after this change but that you think should be
conforming. Reading your proposed replacement text I am at a loss to
see how the effect of it differs from that in the interp. (If there
is a difference, I'm sure I could work it out eventually, but you must
have something in mind already, right?)
Van replied to Malcolm:
I had in mind the case of common block declarations resulting in
partial and overlapping storage associations of numeric sequence type
objects in such a way that their ultimate storage-associated components
have the same types and kinds. That is, defining any component
wouldn't undefine anything.
Suppose for example that in one scoping unit there is a common block
with two numeric sequence type objects, each having two default integer
components. In another there is the same common block with a default
integer, a sequence type object with two default integer components,
and another default integer. Assigning to any of the numeric sequence
objects shouldn't undefine anything.
result of ballot on F03/0124:
/interp will take this back for more work to solve the closely-related
problem raised by Van. We probably hwill be editing the same text to
solve Van's extra problem => F03/0124 fails.
** end negative comments
----------------------------------------------------------------------
NUMBER: F03/0128
TITLE: Subobjects in namelist output
KEYWORDS: NAMELIST
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Was it intended to disallow vendors to provide namelist output that
includes a subobject designator followed by a value?
ANSWER:
Yes. The processor is required to produce output in the form
specified by 10.11.4.3 "Namelist output records".
10.11.4.3 paragraph 2 states
"The name of each namelist group object list item is placed in the
output record followed by an equals and a list of values of the
namelist group object list item."
This unambiguously states that each namelist group object list item
(these are the ones listed in NAMELIST statements) have their names
placed in the output record followed by an equals sign and the list
of their values. Subobject designators do not appear in NAMELIST
statements.
EDIT:
None.
SUBMITTED BY: John Reid
HISTORY: 09-115 m187 F03/0128 submitted
09-115r1 m187 Passed by J3 meeting + F2008 fix {pulled}
09-187r2 m188 Failed J3 letter ballot #18 09-155: accept
edit line number change, F2008 fix from m187
does not appear in 09-007r1;
10-239 m193 Revised answer - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0006
TITLE: Generic resolution, intrinsic procedures, and host association
KEYWORDS: intrinsic, generic, host association
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
The specifications of some intrinsic functions and subroutines
explicitly ban certain combinations of arguments, even though those
combinations are included in the title and the argument portion of the
specification of the function or subroutine. Examples include CMPLX
and RANDOM_SEED. Other requirements include being a valid KIND type
parameter value (e.g. INT) or having having character length 1
(e.g. ICHAR).
Consider the program fragment
PROGRAM p
INTERFACE cmplx
LOGICAL FUNCTION mycmplx(a,b)
COMPLEX a
REAL b
END
END INTERFACE
INTERFACE random_seed
SUBROUTINE my_random_seed(get,put,size)
INTEGER,OPTIONAL :: get(:),put(:),size
END SUBROUTINE
END INTERFACE
INTERFACE int
INTEGER FUNCTION myint(i,j)
END
END INTERFACE
COMPLEX :: z = (1,2)
REAL :: r = 3
CALL check
CONTAINS
SUBROUTINE check
INTRINSIC int,cmplx,random_seed
PRINT *,cmplx(z,r) ! Reference (1).
CALL random_seed(GET=a,PUT=b) ! Reference (2).
PRINT *,int(3,17) ! Reference (3).
END SUBROUTINE
END PROGRAM
Are the procedure references (1), (2), and (3) invalid references to
the intrinsic procedures CMPLX, RANDOM_SEED, and INT, or are they
valid references to the user procedures mycmplx, my_random_seed, and
myint respectively?
ANSWER:
Reference (1) is a valid reference to the user procedure.
Both references (2) and (3) are invalid references to the intrinsic
procedures; however, no constraints are violated so a standard-
conforming processor may do anything, including treating them as
references to the user procedures.
DISCUSSION:
12.5.5.2 paragraph 4 explains that the reference is to the intrinsic
procedure if it is "consistent with the interface of that intrinsic
procedure". The interface to an intrinsic procedure consists of its
name, characteristics, and dummy argument names. The characteristics
of a procedure as defined by 12.4.1 do not include arbitrary
restrictions such as those for RANDOM_SEED which are on argument
presence (an execution time concept). Nor are requirements such as an
actual argument being required to be a constant expression part of an
interface.
In the case of CMPLX however, there is no specific version whose
interface has an X argument of type COMPLEX and any Y argument.
13.7.36 describes this by "If X is of type complex, no actual argument
shall correspond to Y". Therefore the reference to CMPLX with such
arguments is not consistent with the intrinsic.
EDITS to 10-007:
None.
SUBMITTED BY: Robert Corbett
HISTORY: 10-153 m192 F08/0006 submitted
10-153r1 m192 Draft answer
10-153r2 m192 Revised answer - Passed by J3 meeting
10-202 m192 Amended by J3 letter ballot 10-199; failed
J3 letter ballot 10-199
10-236 m193 Revised answer for F2008
10-236r1 m193 Revised example - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0040
TITLE: MOVE_ALLOC for coarrays
KEYWORDS: intrinsic, allocation
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Was it intended that MOVE_ALLOC be applicable to coarrays?
ANSWER:
No. A call to MOVE_ALLOC on coarrays might involve the deallocation
of a coarray; therefore MOVE_ALLOC would need to be an image
control statement for consistency with the DEALLOCATE statement.
An edit is supplied to clarify this.
EDIT: In 10-007
In 13.7.118p3 MOVE_ALLOC (FROM, TO):
[372:18] After "It shall be allocatable." in FROM, add
"It shall not be a coarray."
[372:19] After "It shall be allocatable." in TO, add
"It shall not be a coarray."
SUBMITTED BY: John Reid
HISTORY: 10-200 m193 F08/0040 submitted
10-200r1 m193 Answer edited - Passed by J3 meeting
11-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------
NUMBER: F08/0041
TITLE: Segment ordering rules
KEYWORDS: segment, allocation
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress
QUESTION:
(1) Was it intended to allow the allocation of a variable that is not
a subobject of a coarray to be unordered with respect to its
definition by another image through a pointer component of a
coarray?
For example,
PROGRAM example1
TYPE t1
REAL,ALLOCATABLE :: c(:)
END TYPE
TYPE t2
TYPE(t1),POINTER :: p
END TYPE
TYPE(t1),TARGET :: x
TYPE(t2) :: y[*]
y%p => x ! y[n]%p => x[n] for all n.
SYNC ALL
IF (THIS_IMAGE()==1) THEN
ALLOCATE(x%c(1000)) ! Allocates x[1]%c.
ELSE
y[1]%p%c(THIS_IMAGE()) = 999 ! Defines some part of x[1]%c.
END IF
END PROGRAM
(2) If a variable is already defined (initially or by some segment
that precedes all other segments in this question), may one image
reference it while another image causes it to become undefined in
unordered segments?
For example, is
PROGRAM example2
REAL :: x(100)[*]
x = 1
SYNC ALL
IF (THIS_IMAGE()==1) THEN
PRINT *,SUM(x)
ELSE
CALL destroy(x)
END IF
CONTAINS
SUBROUTINE destroy(x)
REAL,INTENT(OUT) :: x(:)
END SUBROUTINE
END PROGRAM
standard-conforming? This does not appear to violate any of the
segment ordering requirements in 8.5.2 because it is not defined in
any unordered segment (so bullet 1 does not apply), there is no
allocation or pointer association status (so bullet 2 does not apply),
and there is no dummy argument being defined (so bullet 3 does not
apply).
ANSWER:
(1) No, this example violates the requirement of the first bullet in
paragraph 3 of 8.5.2, which says:
"if a variable is defined on an image in a segment, it shall not
be referenced, defined, or become undefined in a segment on
another image unless the segments are ordered".
x[1]%c is defined in segment 2 by images 2-N, but is made
undefined on image 1 (allocation makes a variable undefined except
when default initialization occurs).
(2) No, this example was not intended to be standard-conforming. An
edit is supplied to clarify the intent.
EDITS to 10-007:
[189:14] In 8.5.2 paragraph 3, first bullet point,
After "if a variable is defined"
Insert "or becomes undefined"
(before "on an image in a segment").
{Forbid uncoordinated undefinings of variables.}
SUBMITTED BY: John Reid
HISTORY: 10-201 m193 F08/0041 submitted
10-201r1 m193 Revised - Passed by J3 meeting
11-xxx m194 Failed J3 letter ballot #22 10-254
** start negative comments
John Reid's NO vote on F08/0041:
There are errors in both examples. In example (1), the component of
type t2 should have type t1. In example (2), the PRINT statement
should reference x on another image, e.g. PRINT *, x(1)[2].
More seriously, the edit proposed in 10-201 has been removed. While it
is not necessary for allocation, it is needed for pointer association.
This means that it is desirable to rewrite the questions and answers.
Here is my suggestion
QUESTION:
(1) If a variable is already defined (initially or by some segment
that precedes all other segments in this question), may one image
reference it while another image causes it to become undefined in
unordered segments?
For example, is
PROGRAM example2
REAL :: x(100)[*]
x = 1
SYNC ALL
IF (THIS_IMAGE()==1) THEN
PRINT *,x(1)[2]
ELSE
CALL destroy(x)
END IF
CONTAINS
SUBROUTINE destroy(x)
REAL,INTENT(OUT) :: x(:)
END SUBROUTINE
END PROGRAM
standard-conforming? This does not appear to violate any of the
segment ordering requirements in 8.5.2 because it is not defined in
any unordered segment (so bullet 1 does not apply), there is no
allocation or pointer association status (so bullet 2 does not apply),
and there is no dummy argument being defined (so bullet 3 does not
apply).
(2) Was it intended to allow a pointer assignment to a pointer that is
not a subobject of a coarray to be unordered with respect to its
definition by another image through a pointer component of a
coarray?
For example,
PROGRAM example1
TYPE t
REAL,POINTER :: p
END TYPE
REAL,TARGET :: a=0.0, b=1.0
TYPE(t) :: y[*]
y%p => a ! y[n]%p => a for all n.
SYNC ALL
IF (THIS_IMAGE()==1) THEN
y%p => b ! y[1]%p => b
ELSE
y[1]%p = 999 ! Defines a[1] or b[1]?
END IF
END PROGRAM
ANSWER:
(1) No. This case has been overlooked in the segment ordering rules.
An edit is supplied to correct this.
(2) No. This case, too, has been overlooked in the segment ordering
rules. An edit is supplied to correct this.
EDITS to 10-007:
[189:14] In 8.5.2 paragraph 3, first bullet point,
After "if a variable is defined"
Insert "or becomes undefined"
(before "on an image in a segment").
[189] In 8.5.2 Segments, paragraph 3, replace the second bullet item by
"if the allocation or the pointer association status of a variable
is changed on an image in a segment, that variable shall not be
referenced or defined in a segment on another image unless the
segments are ordered, and".
Van Snyder's No vote on F08/0041:
"is defined" is a static concept. The requirement should
always have been "becomes defined". Therefore the edit should
be to replace "variable is defined" to "variable becomes
defined or undefined" -- or do we need another interp to
repair this?
Jim Xia's No vote on F08/0041:
The first example should be fixed to have t2 contains a pointer
component of type t1. The second example is perfectly legal. Seems
we need to rework on this interp.
result of ballot on F08/0041:
In example (1), the component of type t2 is changed to type t1.
However, more work is needed on this interp as a result of these
comments => F08/0041 fails.
The edit in 10-201 referred to above is:
[189] In 8.5.2 Segments, paragraph 3, replace the second bullet
item by
"if the allocation or the pointer association status of a variable
is changed on an image in a segment, that variable shall not be
referenced or defined in a segment on another image unless the
segments are ordered, and"
** end negative comments
----------------------------------------------------------------------
NUMBER: F08/0042
TITLE: SOURCE= questions
KEYWORDS: ALLOCATE, SOURCE=
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the program
PROGRAM example1
REAL,ALLOCATABLE :: x(:),y(:)
ALLOCATE(x(10),y(10),SOURCE=3.14159265)
PRINT *,x,y
END
This program does not conform to Fortran 2003 due to constraint C631
which stated
"If SOURCE= appears, ... shall contain only one
...".
The corresponding constraint in Fortran 2008, C638, is missing this
requirement, so apparently the program is now syntactically correct.
However, the Introduction to the Fortran 2008 standard does not
mention this as a new feature.
Furthermore, 6.7.1.1 paragraph 4 begins
"If is a coarray, shall not have a
dynamic type of ..."
which implies that there is only one for a
(at least when the is a coarray).
Similarly, the wording of constraint C639 implies a one-to-one
correspondence between and .
Q1. Is the omission of the single allocation requirement of Fortran
2003 an oversight? (i.e. is example1 non-conforming?).
Also, consider the program
PROGRAM example2
REAL,ALLOCATABLE :: x[:]
ALLOCATE(x)
x = 3
END
The ALLOCATE statement appears not to conform to Fortran 2008 because
of 6.7.1.1 paragraph 4; since does not appear, it cannot
satisfy any condition about its dynamic type.
Q2. Is an ALLOCATE statement for a coarray required to have SOURCE=?
(i.e. is example2 non-conforming?).
Also, if multiple allocations with SOURCE= are permitted,
consider the program
PROGRAM example3
INTEGER,ALLOCATABLE :: x,y
ALLOCATE(x,y,SOURCE=f())
PRINT *,x,y
CONTAINS
INTEGER FUNCTION f()
INTEGER,SAVE :: n = 1
f = n
n = n + 1
END FUNCTION
END PROGRAM
The execution semantics of SOURCE= in 6.7.1.2 paragraph 7 do not state
whether the is evaluated once per statement or once per
allocation. If the processor evaluates per statement execution,
something like " 1 1" will be printed, but if it evaluates it per
allocation, something like " 1 2" could be printed.
Q3. How many times may be evaluated in an ALLOCATE
statement with multiple allocations?
Also, consider the program
PROGRAM example4
REAL,ALLOCATABLE :: x(:)
ALLOCATE(x,SOURCE=[0.5,1.5])
PRINT *,x
END PROGRAM
The Introduction implies that this program should be standard-
conforming, but it violates constraint C633, which begins
"(R631) If is an array either shall appear or shall appear ..."
The requirements of C633 are not satisfied because R631 is
and does not appear in R631.
Q4. Is example4 intended to be standard-conforming?
ANSWER:
The answer to question 1 is No.
This feature was deliberately added to the Fortran 2008 standard.
Edits are supplied to correct its exposition.
The answer to question 2 is No.
An edit is supplied to correct paragraph 4 of 6.7.1.1.
The answer to question 3 is once.
An edit is supplied to clarify paragraph 7 of 6.7.1.2.
The answer to question 4 is Yes.
An edit is supplied to correct constraint C633.
EDITS:
{to 10-007}
[xiii] Introduction, bullet "Data usage and computation",
Before "MOLD="
Insert "Multiple allocations are permitted in a single ALLOCATE
statement with SOURCE=."
{(Q1) Add new feature to the feature list.}
[126:31-33] Replace C633 entirely with the constraints
"C633 (R626) If an is an array, either shall appear in its or shall appear in the ALLOCATE statement.
C633a (R631) If is scalar, shall not appear."
{(Q4) Fix broken constraint.}
[127:5] Constraint C639, replace entirely with
"C639 (R626) If appears, the kind type parameters of
each shall have the same values as the
corresponding type parameters of ."
{(Q1) Fix singular implication. Avoid introducing any implication
that each has the same set of kind type parameters
or that any has the same set of kind type
parameters as the - the relationship is a subset.}
[127:18] 6.7.1.1 paragraph 4, replace entirely with
"If has a dynamic type of C_PTR, C_FUNPTR, LOCK_TYPE,
or has a subcomponent whose dynamic type is LOCK_TYPE, no
in that statement is permitted to be a coarray."
{(Q2) Fix implied requirement of SOURCE= appearance for coarrays.}
[128:26] 6.7.1.2 paragraph 7, append new sentence
"The is evaluated exactly once for each execution of
an ALLOCATE statement."
{(Q3) Clarify number of evaluations.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 10-211 m193 F08/0042 submitted - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0043
TITLE: Executing a type-bound procedure on a coindexed object
KEYWORDS: coarrays, polymorphism
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the following program:
module m
type :: foo
integer :: i = 0
contains
procedure, pass :: op
end type
contains
subroutine op(this, i)
class(foo) :: this
this%i = i
end subroutine
end module m
program p
use m
class(foo), allocatable :: o_foo[:]
integer :: me
allocate(foo :: o_foo[*])
me = this_image()
if (me == 1) then
call o_foo[2]%op(1) ! Type-bound call.
end if
sync all
if (me == 2) write(*,*) o_foo%i
end program p
This program is not standard-conforming, as it violates one of the
requirements of 12.5.2.4p2, viz
"If the actual argument is a polymorphic coindexed object,
the dummy argument shall not be polymorphic."
However, if the type-bound call were replaced by
SELECT TYPE(o_foo)
TYPE IS (foo)
CALL o_foo[2]%op(1)
END SELECT
appears to be standard-conforming.
The example program appears to be harmless, so the requirement appears
to be unnecessary. It is conjectured that the requirement is
misworded and should instead be
"If the actual argument is a polymorphic subobject of a coindexed
object, the dummy argument shall not be polymorphic."?
Q1. Is this requirement intentional?
Furthermore, constraint C1229 says of a that is the object
for a type-bound procedure reference, that it
"shall not be a polymorphic subobject of a coindexed object";
however, C617 already prohibits any from being a
polymorphic subobject of a coindexed object except as the subject of
a type parameter inquiry or as the actual argument in an intrinsic
inquiry function reference, so C1229 appears to be completely
redundant.
Q2. Is constraint C1229 redundant?
ANSWER:
A1. The requirement is intentional, and needed to avoid a potential
type enquiry of an object on another image. Consider
TYPE,EXTENDS(foo) :: badfoo
CLASS(*),ALLOCATABLE :: badcomponent(:)
END TYPE
If the dynamic type of object "o_foo" were "badfoo", the call to
the type-bound procedure cannot be resolved without enquiring the
type of o_foo%badcomponent on image 2 (because it needs to know
how much to copy, and how); this type is not necessarily the
same type as that of o_foo%badcomponent on image 1.
A2. Yes, constraint C1229 is redundant. An edit is supplied to remove
this unnecessary redundancy.
EDITS to 10-007:
[290:1] Delete C1229.
SUBMITTED BY: R. Bader
HISTORY: 10-208 m193 F08/0043 submitted
10-208r1 m193 Revised - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0044
TITLE: Resolving the type of a coarray or coindexed object
KEYWORDS: coarrays, polymorphism
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTIONS:
Consider the following code:
module m
type :: foo
integer :: i = 0
end type
end module m
program p
use m
class(foo), allocatable :: o_foo[:]
integer :: j
allocate(foo :: o_foo[*])
if (this_image() == 1) then
select type(a => o_foo[2]) ! 1
type is(foo)
j = a%i
end select
select type(a => o_foo) ! 2
type is(foo)
j = a[2]%i
end select
select type(o_foo) ! 3
type is(foo)
j = o_foo[2]%i
end select
end if
end program p
(1) Is the first SELECT TYPE block standard-conforming?
(2) Is the second SELECT TYPE block standard-conforming?
(3) Is the third SELECT TYPE block standard-conforming?
ANSWERS: References are to 10-007
(1) No.
is in the definition of in R847 [184:10].
is defined in R805 [170:17]. C803 [170:22] disallows a
coindexed object if is a . C803 constrains
in both and .
(2) Yes.
This is implied by 8.1.3.3 para 1 [171:2].
(3) Yes.
EDITS:
None
SUBMITTED BY: R. Bader
HISTORY: 10-209 m193 F08/0044 submitted
10-209r1 m193 Proposed answer - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0045
TITLE: constraints on entities of type LOCK_TYPE
KEYWORDS: lock, polymorphism
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress
QUESTION:
Consider the following program:
Program example
Use Iso_Fortran_Env, Only:lock_type
type :: m
class(*), allocatable :: lock
end type
type(m) :: om[*]
allocate(lock_type :: om%lock)
call inner(om) ! Problem call.
Contains
Subroutine inner(omm)
Type(m),Intent(Out) :: omm
Print *,Allocated(omm%lock)
End Subroutine
End Program
Constraint C1304 attempts to prohibit a variable with a LOCK_TYPE
subobject from appearing in a variable definition context, such as the
call to inner, but the dynamic type of om%lock cannot be determined
statically.
Is this program standard-conforming?
ANSWER:
The example was not intended to be standard-conforming. An ALLOCATE
statement with a should not have been permitted to add
components of type LOCK_TYPE; an edit is supplied to correct this
error.
EDITS to 10-007:
[127:7] In C641,
After "C_PTR" replace "or" by ",";
After "C_FUNPTR" insert
", LOCK_TYPE (13.8.2.16), or a type with a direct component of
type LOCK_TYPE that is not a direct component of the declared
type of any ,".
{Fix condition to prohibit LOCK_TYPE and any type with a LOCK_TYPE
direct component. Note that we only want to prohibit "new" lock_type
components from appearing in the , we don't want to forbid
ones that are already in the declared type.}
[127:8] After "LOCK_TYPE" delete "(13.8.2.16)".
{Reference now appears one line earlier, so is unnecessary.}
SUBMITTED BY: R. Bader
HISTORY: 10-210 m193 F08/0045 submitted
10-210r1 m193 Revised - Passed by J3 meeting
11-xxx m194 Failed by J3 letter ballot #22 10-254
** start negative comments
Jim Xia's No vote on F08/0045:
The edits makes it illegal to specify LOCK_TYPE as if the
coarray itself is of LOCK_TYPE. For example,
type(lock_type), allocatable :: locks[*]
The edits make the following allocate statement illegal
ALLOCATE (LOCK_TYPE: locks[*])
result of ballot on F08/0045:
/interp will take this back for more work since we think that Jim has
a valid complaint => F08/0045 fails
Perhaps the edit should be changed to
[127:7] In C641,
After "C_PTR" replace "or" by ",";
After "C_FUNPTR" insert
", or a type with a direct component of type LOCK_TYPE
(13.8.2.16) that is not a direct component of the declared
type of any ,".
[127:7+] Insert new constraint
"C641a (R626) If an is unlimited polymorphic,
shall not specify the type LOCK_TYPE
(13.8.2.16)."
** end negative comments
----------------------------------------------------------------------
NUMBER: F08/0046
TITLE: VALUE attribute restrictions
KEYWORDS: VALUE
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the program unit
SUBROUTINE s(x,y,n)
REAL,VALUE :: x(:)
CHARACTER(n),VALUE :: y
DO i=2,SIZE(x)
x(i) = x(i) + x(i-1)
END DO
PRINT *,y,x
END SUBROUTINE
This is not valid in Fortran 2003 as it violates constraint C527
"If the VALUE attribute is specified, the ... DIMENSION
... attribute shall not be specified."
and also violates constraint C528
"If the VALUE attribute is specified, the length type parameter
values shall be omitted or specified by initialization
expressions."
The corresponding constraint to F2003/C527 for Fortran 2008, C558,
does not prohibit the DIMENSION attribute. There does not appear to
be any constraint in F2008 corresponding to F2003/C528. Therefore
this program unit is apparently now syntactically correct.
However, the Introduction to the Fortran 2008 standard does not
mention these as new features.
Is the omission of these requirements an oversight?
ANSWER:
No, these are deliberate additions to the language. An edit is
supplied to clarify the Introduction.
EDITS:
{to 10-007}
[xiii] Introduction, bullet "Data declaration", append
"The VALUE attribute is permitted for an array, and for an object
with a nonconstant length type parameter."
SUBMITTED BY: Malcolm Cohen
HISTORY: 10-212 m193 F08/0046 submitted - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0047
TITLE: public generic with same name as private type
KEYWORDS: generic, accessibility
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
Consider the following code:
module m
implicit none
private
public :: foo ! A
type, private :: foo ! B
integer :: i = 0
end type
type(foo), public :: o_foo
interface foo
module procedure foo_proc
end interface
contains
function foo_proc(i) result(this)
integer, intent(in) :: i
type(foo) :: this
this%i = i
write(*, *) 'Hello'
end function
end module m
program p
use m
implicit none
o_foo = foo(2)
end program
QUESTION:
Is this program standard conforming?
ANSWER:
No.
DISCUSSION:
The PUBLIC statement at A contradicts the PRIVATE attribute at B which
violates the standard.
SUBMITTED BY: R. Bader
HISTORY: 10-213 m193 F08/0047 submitted
10-213r1 m193 Proposed answer - Passed by J3 meeting
11-xxx m194 Passed by J3 letter ballot #22 10-254
----------------------------------------------------------------------
NUMBER: F08/0048
TITLE: Sequence association for coarrays
KEYWORDS: sequence association, coarrays
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress
QUESTION:
Was the text in 12.5.2.8:
"If the dummy argument is an array coarray that has the CONTIGUOUS
attribute or is not of assumed shape, the corresponding actual
argument shall be simply contiguous."
intended to disallow sequence association for coarrays, as illustrated
by the example
interface
subroutine sub (x)
real x(10)[*]
end subroutine
end interface
...
real :: x(100)[*]
...
call sub (x(10))
12.5.2.4 paragraph 13 seems to imply that this ought to be valid.
ANSWER:
Yes, passing an array element to a dummy coarray was not intended to
use sequence association. There is no contradiction with 12.5.2.4
paragraph 13 (which as is simply doesn't apply), but it is confusing
so an edit is supplied to clarify it.
EDIT:
[294:33] Append new sentence to 12.5.2.4 paragraph 13,
"If the dummy argument is a coarray that is an array, the actual
argument shall be an array."
SUBMITTED BY: John Reid
HISTORY: 10-226 m193 F08/0048 submitted
10-226r1 m193 Revised answer
10-226r2 m193 Passed by J3 meeting
11-xxx m194 Failed J3 letter ballot #22 10-254
** start of negative comments
Bill Long's No vote on F08/0048:
The proposed restriction on coarrays as actual arguments
sequence associated with a contiguous dummy makes yet another
exception to ordinary array behavior for coarrays. In this case, there
seems to be no justification other than the view that sequence
association of arguments is archaic. I think that the confusion
introduced by making another case where coarrays are different from
ordinary arrays is less desirable that allowing coarrays to behave
like "old" arrays.
John Reid's NO vote on F08/0048:
Sequence association is allowed for array coarrays, so I can see no
reason for disallowing it for a scalar coarray that is an element of
a simply contiguous array.
12.5.2.4 para 13 says: "If the actual argument is a noncoindexed
scalar, the corresponding dummy argument shall be scalar unless the
actual argument is default character, of type character with the C
character kind (15.2.2), or is an element or substring of an element
of an array that is not an assumed-shape, pointer, or polymorphic
array."
As the standard stands, I believe that this applies. It is made not
to apply by the new edit: "If the dummy argument is a coarray that
is an array, the actual argument shall be an array."
I think this is a technical change that contradicts one of our design
principles: wherever possible, coarrays should behave just like
variables that are not coarrays.
I suggest that we go back to 10-226 which contains the edit
In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2
[297:9], add "or an element of a simply contiguous array".
Jim Xia's No vote on F08/0048:
I believe this restriction might be a bit surprising to users who
regularly use sequence associations. Also there isn't an apparent
technical difficulties in support this.
** end of negative comments
----------------------------------------------------------------------
NUMBER: F08/0049
TITLE: ELEMENTAL functions with nonconstant type parameters
KEYWORDS: ELEMENTAL, type parameter
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Interpretation F03/0119, which became part of the Fortran 2008
standard, added as constraint the requirement of an elemental function
that its result variable
"shall not have a type parameter that is defined by an expression
that is not a constant expression".
This makes a number of valid Fortran 95 programs invalid, for no
apparent technical reason. Moreover, no text was added to clause 1 to
indicate this incompatibility with Fortran 95.
Here are several examples of non-problematic Fortran 95 elemental
procedures that are apparently not valid Fortran 2008.
MODULE ex1
INTEGER :: mylen
CONTAINS
ELEMENTAL CHARACTER(mylen) FUNCTION f(a)
INTEGER,INTENT(IN) :: a
f = REPEAT(CHAR(a),mylen)
END FUNCTION
END MODULE
ELEMENTAL FUNCTION ex2(a,b)
CHARACTER(*),INTENT(IN) :: a,b
CHARACTER(LEN(a)+LEN(b)) :: ex2
ex2 = a//b
END FUNCTION
MODULE ex3
INTEGER,ALLOCATABLE :: x(:)
CONTAINS
PURE FUNCTION gcd(a)
INTEGER :: gcd
INTEGER,INTENT(IN) :: a(:)
gcd = ... code to calculate this omitted ...
END FUNCTION
ELEMENTAL FUNCTION f(y,z)
CHARACTER(*),INTENT(IN) :: y,z
CHARACTER(gcd([x,LEN(y),LEN(z)])) :: f
f = ...
END FUNCTION
END MODULE
Was this incompatibility with Fortran 95 an oversight?
ANSWER:
Yes, this was an oversight; requiring the type parameter values to be
constant is unnecessarily onerous. An edit is supplied to correct
this defect in the standard.
EDITS:
{to 10-007}
[314:6-7] 12.8.1, C1290, delete ", and shall not ... expression".
{Delete erroneous constraint.}
[314:7+] Insert new constraint
"C1290a In the that specifies a type parameter
value of the result of an elemental function, an object
designator with a dummy argument of the function as the base
object shall appear only as the subject of a specification
inquiry, and that specification enquiry shall not depend on
a property that is deferred."
SUBMITTED BY: Malcolm Cohen
HISTORY: 10-231 m193 F08/0049 submitted - Passed by J3 meeting
11-xxx m194 Passed as amended by J3 letter ballot
#22 10-254
----------------------------------------------------------------------