ISO/IEC JTC1/SC22/WG5 N1622
WG5 letter ballot 2 on Fortran 2003 interpretations
John Reid, 8 April 2005
This is the second set of draft interpretations for Fortran 2003. 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 2003 interpretations are being balloted:
Yes No Number Title
--- --- F03/0030 IEEE divide by zero
--- --- F03/0031 IEEE invalid
--- --- F03/0032 Sign bit of IEEE NaN
--- --- F03/0033 IEEE_VALUE()
--- --- F03/0034 IEEE_LOGB()
--- --- F03/0035 IEEE_NEXT_AFTER()
--- --- F03/0036 IEEE_REM()
--- --- F03/0037 IEEE_RINT()
--- --- F03/0038 IEEE_SCALB()
--- --- F03/0039 HYPOT()
--- --- F03/0040 2.0+2.0 and IEEE
--- --- F03/0041 IEEE halting and exceptions
--- --- F03/0043 Passed-object arguments and procedure
pointer components
--- --- F03/0044 Implicit interfaces and conflicting
references
--- --- F03/0045 Finalization and assumed-
arguments with INTENT(OUT)
--- --- F03/0046 Unlimited polymorphic pointers in
common blocks
--- --- F03/0047 Polymorphic arguments to intrinsic
procedures
--- --- F03/0052 ADVANCE= specifier in child data
transfer statements
--- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR
--- --- F03/0054 Denormal inputs to EXPONENT, FRACTION,
and SET_EXPONENT
--- --- F03/0055 Denormal inputs to SPACING and RRSPACING
The text of these interpretations is attached. Each interpretation
starts with a row of "-"s.
Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send only the
above text {not this entire mail mail message} to
sc22wg5@dkuug.dk
by 8 a.m (UK time) on Friday, 6 May 2005, in order to be counted.
Thanks,
John.
======================================================================
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 IEEE-754).
The definitions in 14.2 were intended to describe IEEE exceptions with
sufficient latitude to allow use on near-IEEE and non-IEEE machines.
However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with
the IEEE International Standard.
Furthermore, the definition of the IEEE_OVERFLOW flag is also not
consistent with the IEEE standard, because this exception is not
raised for operations on infinite operands.
Edits are provided to fix these inconsistencies.
EDITS:
Page and line numbers refer to 04-007.
[365:13-15] Clause 14.2, lines 3 and 5. After "assignment" add
"with finite operands", twice.
[365:18] Clause 14.2, line 8. Change "nonzero numerator" to
"finite nonzero numerator".
SUBMITTED BY: Fred Tydeman
HISTORY: 05-109 m171 Submitted
05-109r1 m171 Revised to include IEEE_OVERFLOW,
Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0031
TITLE: IEEE invalid
KEYWORDS: IEEE-754, invalid exception
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
What exceptions (if any) are raised by the following:
infinity + (-infinity)
infinity - infinity
0.0 * infinity
infinity / infinity
0.0 / 0.0
Fortran 2003 is silent on these expressions.
IEEE-754 defines (in 7.1) those as invalid.
ANSWER:
The Fortran Standard and Technical Report ISO/IEC TR 15580 were
written to supplement the IEEE International Standard and to allow
for systems that do not fully support it. That the IEEE International
Standard is a normative reference is made clear in 1.9.
The questions related to infinity are answered by the third paragraph
of 14.8, which states
"The inquiry function IEEE_SUPPORT_INF is provided to inquire whether
the processor supports IEEE infinities. Where these are supported,
their behavior for unary and binary operations, including
those defined by intrinsic functions and by functions in intrinsic
modules, shall be consistent with the specifications in the IEEE
International Standard."
The expression 0.0 / 0.0 is defined as invalid by the IEEE
International Standard and therefore causes the exception
IEEE_INVALID to occur.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-110 m171 Submitted
05-110r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0032
TITLE: Sign bit of IEEE NaN
KEYWORDS: IEEE-754, NaN, sign bit, negative
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
Do IEEE-754 NaNs have a sign bit? Can they be negative? Does a
sign bit imply a value can be either positive or negative?
Fortran 2003 in 14.10.2 (IEEE_COPY_SIGN) says that NaNs have a
sign bit. But, 14.10.10 (IEEE_IS_NEGATIVE) says NaNs are not
negative. This appears to be a contradiction between two parts
of Fortran 2003.
ANSWER:
The representation of a NaN has a sign bit, and this is what is
referred to in 14.10.2. However, that bit is not interpreted as
a sign (see IEEE standard, 6.3 "This standard does not interpret the
sign of a NaN"). Thus 14.10.10 correctly says that a NaN is never
negative.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-111 m171 Submitted
05-111r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0033
TITLE: IEEE_VALUE()
KEYWORDS: IEEE-754, IEEE_VALUE
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
What does "Generate an IEEE value" in 14.9.2 mean?
Fortran 2003 in 14.9.2 has: "Generate an IEEE value" without any
explanation of what that means, nor any indication that it is
defined elsewhere.
ANSWER:
14.9 contains tables of procedures with a short description of each,
modeled on 13.5. Each procedure is specified in 14.10 and the
reader should have no difficulty in finding its specification there.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-112 m171 Submitted
05-112r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0034
TITLE: IEEE_LOGB()
KEYWORDS: IEEE-754, logb()
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
What is logb(denormal)? Is it of the hardware representation,
or is it as if the hardware had an unbounded exponent range?
What is logb(NaN)? logb(-INF)? logb(+INF)?
logb() should be defined as if the hardware representation had
an unbounded exponent range.
logb(NaN) should be the same NaN; shall be a NaN.
logb(-INF) shall be +INF
logb(+INF) shall be +INF
ANSWER:
The first paragraph of 14.8 states "Complete conformance with the
IEEE International Standard is not required, but ... the functions
copysign, scalb, logb, nextafter, rem, and unordered shall be
provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB,
IEEE_NEXT_AFTER, IEEE_REM, and IEEE_UNORDERED."
Case (i) of 14.10.12 correctly specifies that if the value of X is
denormal, its unbiased exponent is returned; however, the note there
is wrong in this case. An edit is supplied.
For consistency with the IEEE International Standard, an edit is
also supplied for the case where X is infinite.
EDITS:
Page and line numbers refer to 04-007.
[376:15]. Subclause 14.10.12, Result Value, line 2. After "Note:" add
"if X is normal,".
[376:17+]. Subclause 14.10.12, Result Value. Add extra case:
"Case (iii) If IEEE_SUPPORT_INF(X) is true and X is infinite, the
result is +infinity." .
SUBMITTED BY: Fred Tydeman
HISTORY: 05-113 m171 Submitted
05-113r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0035
TITLE: IEEE_NEXT_AFTER()
KEYWORDS: IEEE-754, nextafter()
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
What is NEXT_AFTER(+0.0,-0.0)? NEXT_AFTER(-0.0,+0.0)?
What is NEXT_AFTER(X,Y) if X and/or Y is NaN?
C99 and IEEE-754R (the revision of IEEE-754 now in progress)
define NEXT_AFTER(X,Y) as Y (not X) when X == Y.
NEXT_AFTER(X,Y) when both X and Y are NaN shall be a NaN, and
should be one of NaN arguments.
NEXT_AFTER(X,Y) when one of X and Y is a NaN shall be a NaN, and
should the NaN argument.
ANSWER:
The first paragraph of 14.8 states "Complete conformance with the
IEEE International Standard is not required, but ... the functions
copysign, scalb, logb, nextafter, rem, and unordered shall be
provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB,
IEEE_NEXT_AFTER, IEEE_REM, and IEEE_UNORDERED."
For NEXT_AFTER(X,Y) with X == Y == 0, the result is X, see 14.10.13,
Case (i). This is the recommendation of the IEEE International
Standard. The current draft revision of that Standard uses the
definition copysign(x,y) in this case. We will reconsider the Fortran
definition of NEXT_AFTER if a revised IEEE Standard is adopted
with this change present.
The case of NEXT_AFTER(X,Y) when one or both of X and Y is a NaN
is as defined by the IEEE International Standard, see the words
from 14.8 quoted above.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-114 m171 Submitted
05-114r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0036
TITLE: IEEE_REM()
KEYWORDS: IEEE-754, remainder()
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
What is REM(infinity,Y)? REM(X,0.0)?
What is REM(X,Y) if X and/or Y is NaN?
IEEE-754 requires (in 7.1) both REM(infinity,Y) and REM(X,0.0)
shall be a NaN and raise invalid.
REM(X,Y) when both X and Y are NaN shall be a NaN, and should be
one of the NaN arguments.
REM(X,Y) when one of X and Y is a NaN shall be a NaN, and should
be the NaN argument.
ANSWER:
The first paragraph of 14.8 states "Complete conformance with the
IEEE International Standard is not required, but ... the IEEE
operation rem shall be provided by the function IEEE_REM."
The behaviour of IEEE_REM for the cases cited here is as defined
for REM by the IEEE International Standard.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-115 m171 Submitted
05-115r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0037
TITLE: IEEE_RINT()
KEYWORDS: IEEE-754, rint()
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
What is RINT(+infinity)? RINT(-infinity)? RINT(NaN)?
DISCUSSION:
RINT(X) when X is an infinity shall be X.
RINT(X) when X is a NaN shall be a NaN, and should be the NaN
argument.
ANSWER:
The second and third paragraphs of 14.8 state
"The inquiry function IEEE_SUPPORT_NAN is provided to inquire
whether the processor supports IEEE NaNs. Where these are supported,
their behavior for unary and binary operations, including
those defined by intrinsic functions and by functions in intrinsic
modules, shall be consistent with the specifications in the IEEE
International Standard.
The inquiry function IEEE_SUPPORT_INF is provided to inquire whether
the processor supports IEEE infinities. Where these are supported,
their behavior for unary and binary operations, including
those defined by intrinsic functions and by functions in intrinsic
modules, shall be consistent with the specifications in the IEEE
International Standard. "
Therefore, the behaviour of IEEE_RINT for the cases cited here is as
defined by the IEEE International Standard in section 5.5.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-116 m171 Submitted
05-116r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0038
TITLE: IEEE_SCALB()
KEYWORDS: IEEE-754, scalb()
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
What is SCALB(NaN,Y)?
DISCUSSION:
SCALB(X,Y) when X is a NaN shall be a NaN, and should be the NaN
argument.
ANSWER:
The second paragraph of 14.8 states
"The inquiry function IEEE_SUPPORT_NAN is provided to inquire
whether the processor supports IEEE NaNs. Where these are supported,
their behavior for unary and binary operations, including
those defined by intrinsic functions and by functions in intrinsic
modules, shall be consistent with the specifications in the IEEE
International Standard."
Therefore, the behaviour of IEEE_SCALB for the case cited here is as
defined for scalb by the IEEE International Standard.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-117 m171 Submitted
05-117r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0039
TITLE: HYPOT()
KEYWORDS: IEEE-754, hypot()
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
What is HYPOT(NaN,infinity)? HYPOT(NaN,finite)?
HYPOT(X,Y) when X and/or Y is an infinity (even if the other is
a NaN) shall be +infinity. Reason: hypot(), when one of the
arguments is an infinity, is +infinity independent of the
value of the other argument. So, if the NaN argument is
replaced by zero, any finite number, or any infinity,
hypot(infinity,NaN) is still infinity.
HYPOT(X,Y) when X and/or Y is a NaN (and neither is infinite)
shall be a NaN, and should one of the NaN arguments.
ANSWER:
The HYPOT example in note 14.17 illustrates the use of the features
of this section to provide reliable software that is fast in the
uncomplicated case. We did not consider what would happen if one
of the arguments is a NaN and have therefore edited the text slightly.
DISCUSSION:
In fact, if either X or Y is a NaN, the first executable statement
will set HYPOT to a NaN without signaling an exception. The slower
code in the IF construct will therefore not be executed and a NaN
will be returned, which is consistent with the way NaNs are handled
by intrinsic operators, see paragraph 3 of section 6.2 of the
IEEE International Standard.
EDITS:
Page and line numbers refer to 04-007.
[389:12]. Subclause 14.11, Note 14.17, final paragraph, line 2.
Before "exception" add "overflow or underflow".
[389:16+]. Subclause 14.11, Note 14.17, at the end of the final
paragraph, add "This HYPOT function does not handle infinite arguments
in the same way that the hypot function in the C International
Standard does."
SUBMITTED BY: Fred Tydeman
HISTORY: 05-118 m171 Submitted
05-118r3 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0040
TITLE: 2.0+2.0 and IEEE
KEYWORDS: IEEE-754, accuracy, transformation
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
For processors that use IEEE arithmetic, must 2.0+2.0 be 4.0?
May x/5.0 be transformed into x*0.2?
1.4 (6) [2:4-5] has: "This standard does not specify: The
physical properties of the representation of quantities and the
method of rounding, approximating, or computing numeric values
on a particular processor." That has been used as the reason
why 2.0+2.0 is not required to be 4.0.
Section 14 [364:6-13] has: "If a scoping unit has access to
IEEE_DATATYPE of IEEE_FEATURES, within the scoping unit the
processor shall support IEEE arithmetic and return true from
IEEE_SUPPORT_DATATYPE(X) (14.10.23) for at least one kind of
real. Similarly, if IEEE_DENORMAL, IEEE_DIVIDE, IEEE_INF,
IEEE_NAN, IEEE_ROUNDING, or IEEE_SQRT is accessible, within the
scoping unit the processor shall support the feature and return
true from the corresponding inquiry function for at least one
kind of real. In the case of IEEE_ROUNDING, it shall return true
for all the rounding modes IEEE_NEAREST, IEEE_TO_ZERO, IEEE_UP,
and IEEE_DOWN." IEEE-754 specifies methods of rounding and
computing numeric values, and in particular, requires that
2.0+2.0 be 4.0.
So, does section 14 override the weasel words of 1.4(6)? If
not, should something along the lines of: "The requirements of
this section override 1.4(6)" be added to section 14?
Using IEEE arithmetic, x/5.0 and x*0.2 are not equivalent, so
the former may not be transformed into the latter. Does IEEE
arithmetic override 7.1.8.3 and Note 7.18 and prohibit that
transformation? If not, should something along the lines of:
"The requirements of this section override 7.1.8.3" be added to
section 14?
ANSWER:
Yes, for processors that use IEEE arithmetic, 2.0+2.0 and 4.0
have the same value. That is a requirement of the IEEE
International Standard. However, your example is very simple.
For a more complicated expression, the IEEE Standard does not
specify whether intermediate results are kept in extended-
precision registers. The words in Section 1 are applicable
and give compilers the freedom to choose whether to keep
intermediate results in such registers.
No, section 14 does not override the weasel words of 1.4(6).
As you point out, Section 7 allows x/5.0 to be evaluated as
x*0.2. The results may be different on any binary computer.
Section 14 tells us about the rounding that will occur once
the processor has chosen which way to evaluate this.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-119 m171 Submitted
05-119r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0041
TITLE: IEEE halting and exceptions
KEYWORDS: IEEE-754, trapping, exception
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
If a specific Floating-Point (FP) exception flag is raised, and
then HALTING for that FP exception is enabled for the first
time, does the program halt? Or, must the specific FP exception
happen after the halting is enabled for the program to halt?
Section 14.5 [368:1-8] does not answer the question.
ANSWER:
Section 14.5 states "Halting is not precise and may occur
any time after the exception has occurred." It is therefore
processor dependent as to when, if ever, the program
halts.
EDITS: None
SUBMITTED BY: Fred Tydeman
HISTORY: 05-120 m171 Submitted
05-120r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0043
TITLE: Passed-object arguments and procedure pointer components
KEYWORDS:
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Section 4.5.3.3 [52:5-7] of 04-007 indicates that passed-object dummy
arguments are relevant for both type-bound procedures and procedure
pointer components. However, section 12.4.1.1 [268:17-19] of 04-007 on
the passed-object dummy argument and argument association mentions
only type-bound procedures. Should procedure pointer components also
be mentioned in 12.4.1.1?
ANSWER:
Yes. This was an omission in section 12.4.1.1.
EDITS:
[268:17] After "procedure" insert " or a procedure pointer component"
SUBMITTED BY: Bill Long
HISTORY: 05-106 m171 Submitted, passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0044
TITLE: Implicit interfaces and conflicting references
KEYWORDS: implicit interface, procedure pointer, dummy procedure,
procedure reference
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Is the following program legal?
module test_mod
contains
subroutine reference (proc,choice)
! Proc has implicit interface
external :: proc ! Or
! procedure (), pointer :: proc
logical :: choice
if(choice) then
call proc (1.0) ! Call with real argument
else
call proc (1) ! Call with integer argument
end if
end subroutine
subroutine proc_real (x)
real :: x
end subroutine
subroutine proc_integer (i) ! respelled from original submission
! without loss of generality
integer :: i
end subroutine
end module
program test
use test_mod
call reference (proc_real, .true.)
call reference (proc_integer, .false.)
end program
12.3.2.5 says: "The type...of dummy arguments of a procedure
referenced from a scoping unit where the interface of the
procedure is implicit shall be such that the actual arguments
are consistent with the characteristics of the dummy arguments."
We define a procedure reference in 2.5.6 as the "appearance of
procedure designator, ... in a context requiring execution at
that point."
Are both calls to proc above references, at compile time?
If both calls to proc are references then they both need to be
consistent with the interface of the actual argument associated
with the dummy procedure. This is not possible and the program
would be illegal. However, if only the call executed counts as
a reference, than the program is legal.
The same question applies to both dummy procedures and procedure
pointers with implicit interfaces.
ANSWER:
Technically, the question is ill-formed in asking whether the calls
are references "at compile time". The standard does not have a
notion of compile-time.
The calls to proc are indeed references according to the definition
in 2.5.6. This is a purely syntactic notion since a call-stmt is
an example of "a context requiring execution at that point" and proc
is the procedure designator in
call proc(1.0)
and
call proc(1)
12.3.2.5 specifies a requirement, violations of which are not
required to be detected at compile-time (12.3.2.5 is not a
constraint). Every line of the program when it is actually executed
by a standard-conforming processor uses only forms and relationships
defined by the standard [2:9-10], and the program has an
interpretation according to the standard. This program was intended
to be standard conforming.
However, the current language of 12.3.2.5 is confusing. The
requirement on the type of dummy arguments must be laid on the
procedure actually invoked and not on the procedure named in the
procedure reference. A procedure with only an implicit
interface has no nominal dummy arguments on which a requirement
can be levied! (Ask yourself: what are the names of the dummy
argument(s) of proc ?) Put another way, in
call proc (1.0)
proc is a "procedure reference" but proc_real is actually the
procedure referenced.
An edit is supplied to make this clearer.
EDITS:
In [266:8] change "referenced" to "invoked"
SUBMITTED BY: Aleksandar Donev
HISTORY: 05-127 m171 Submitted
05-127r3 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0045
TITLE: Finalization and assumed-size arguments with INTENT(OUT)
KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the following program:
MODULE m
TYPE t
INTEGER :: i
CONTAINS
FINAL :: finalizeT
END TYPE
CONTAINS
ELEMENTAL SUBROUTINE finalizeT(f)
TYPE(t), INTENT(INOUT) :: f
f%i = 10
END SUBROUTINE
END MODULE
SUBROUTINE xyz (d)
USE m
TYPE(t), INTENT(OUT) :: d(*)
END SUBROUTINE
PROGRAM foo
USE m
EXTERNAL xyz
TYPE(t) :: a(10) = t(5)
CALL xyz(a(2))
END PROGRAM
4.5.5.2 of Fortran 2003 states:
When a procedure is invoked, a nonpointer, nonallocatable object
that is an actual argument associated with an INTENT(OUT) dummy
argument is finalized.
For assumed-size arguments, this situation is similar to that of
default initialization with INTENT(OUT). Default initialization is
prohibited for INTENT(OUT), assumed-size dummy arguments by C544. A
similar restriction on finalization may have been overlooked.
Was this program intended to be standard-conforming?
ANSWER:
No, this program was not intended to be standard-conforming. An edit
is supplied to correct this oversight.
EDITS:
All edits refer to 04-007.
[80:9] Before "a type", insert "a finalizable type or".
SUBMITTED BY: Rob James
HISTORY: 05-136 m171 Submitted, passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0046
TITLE: Unlimited polymorphic pointers in common blocks
KEYWORDS: Unlimited polymorphic pointer, common block
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider the following program:
PROGRAM foo
COMMON /blk1/ x
CLASS(*), POINTER :: x
CALL sub
END PROGRAM
SUBROUTINE sub
COMMON /blk1/ x
CLASS(*), POINTER :: x
END SUBROUTINE
There appears to be nothing prohibiting an unlimited polymorphic
pointer from appearing in a common block, but the following appears in
Fortran 2003 at [100:10]:
A data pointer shall be storage associated only with data pointers
of the same type and rank.
And at [75:23-25]:
An object declared with the CLASS(*) specifier is an unlimited
polymorphic object. An unlimited polymorphic entity is not
declared to have a type. It is not considered to have the same
declared type as any other entity, including another unlimited
polymorphic entity.
It appears that it is not standard conforming to have an unlimited
polymorphic pointer that is storage associated with anything else,
including another unlimited polymorphic pointer. So, while it is
apparently standard-conforming to have an unlimited polymorphic
pointer in a common block, a common block with the same name cannot be
accessed in any other scoping unit.
This interpretation also seems to be supported by parts of section 16
of the standard.
At [416:7-24]:
In a storage association context
...
(8) A pointer occupies a single unspecified storage unit that is
different from that of any nonpointer object and is
different for each combination of type, type parameters, and
rank.
At [417:12-13]:
All scoping units that access named common blocks with the same
name shall specify an identical sequence of storage units.
And at [417:14-17]:
For any two blank common blocks, the initial sequence of storage
units of the longer blank common block shall be identical to the
sequence of storage units of the shorter common block. If two
blank common blocks are the same length, they shall have the same
sequence of storage units.
Was it intended that an unlimited polymorphic pointer should be
allowed in a common block? If yes, then was it intended that such a
common block should be accessible in more than one scoping unit?
ANSWER:
No. An edit is provided to correct this oversight.
EDITS:
All edits refer to 04-007.
[98:20] Before "an allocatable variable", insert
"a polymorphic pointer,".
SUBMITTED BY: Rob James
HISTORY: 05-137 m171 Submitted, passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0047
TITLE: Polymorphic arguments to intrinsic procedures
KEYWORDS: polymorphism, intrinsic procedures
DEFECT TYPE: Erratum
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:
Answer 1:
Yes.
Answer 2:
(a) Yes.
(b) In this case, the result is polymorphic. If the argument is
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the argument.
Otherwise, the declared and dynamic types of the result are the
same as those of the argument.
Answer 3:
(a) Yes.
(b) Yes.
(c) The requirements apply to both the declared type and the dynamic
type.
(d) In this case, the result is polymorphic. If the arguments are
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the arguments.
Otherwise, the declared and dynamic types of the result are the
same as those of the arguments.
Answer 4:
(a) Yes.
(b) No.
(c) The requirements refer to the dynamic type.
Answer 5:
(a) Yes.
(b) Yes.
(c) The requirements refer to both the declared type and the dynamic
type.
(d) In this case, the result is polymorphic. If the arguments are
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the arguments.
Otherwise, the declared and dynamic types of the result are the
same as those of the arguments.
Answer 6:
Yes.
Answer 7:
(a) Yes.
(b) Yes.
(c) The requirements refer to both the declared type and the dynamic
type.
(d) In this case, the result is polymorphic. If the arguments are
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the arguments.
Otherwise, the declared and dynamic types of the result are the
same as those of the arguments.
Answer 8:
(a) Yes.
(b) Yes.
(c) The requirements refer to both the declared type and the dynamic
type.
(d) In this case, the result is polymorphic. If the arguments are
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the arguments.
Otherwise, the declared and dynamic types of the result are the
same as those of the arguments.
Answer 9:
(a) Yes.
(b) No.
(c) The requirements refer to the dynamic type.
Answer 10:
(a) Yes.
(b) In this case, the result is polymorphic. If the argument is
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the argument.
Otherwise, the declared and dynamic types of the result are the
same as those of the argument.
Answer 11:
(a) Yes.
(b) No.
(c) N/A.
Answer 12:
(a) Yes.
(b) In this case, the result is polymorphic. If the argument is
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the argument.
Otherwise, the declared and dynamic types of the result are the
same as those of the argument.
Answer 13:
(a) Yes.
(b) Yes.
(c) The requirements refer to both the declared type and the dynamic
type.
(d) In this case, the result is polymorphic. If the arguments are
unlimited polymorphic, then the result is unlimited polymorphic
and its dynamic type is the same as that of the arguments.
Otherwise, the declared and dynamic types of the result are the
same as those of the arguments.
Answer 14:
No.
EDITS:
[292:18+] Insert a new subclause 13.2 and re-number subsequent
subclauses:
13.2 Polymorphic intrinsic function arguments and results
Table 13.1 specifies the intrinsic functions that are allowed to have
polymorphic arguments, and the arguments that are allowed to be
polymorphic.
Table 13.1: Polymorphic intrinsic function arguments
---------------------------------------------------------------
| Function name | Arguments permitted to be polymorphic |
===============================================================
| ALLOCATED | ARRAY, SCALAR |
| ASSOCIATED | POINTER, TARGET |
| CSHIFT | ARRAY |
| EOSHIFT | ARRAY, BOUNDARY |
| EXTENDS_TYPE_OF | A, MOLD |
| LBOUND | ARRAY |
| MERGE | TSOURCE, FSOURCE |
| MOVE_ALLOC | FROM, TO |
| PACK | ARRAY, VECTOR |
| RESHAPE | SOURCE, PAD |
| SAME_TYPE_AS | A, B |
| SHAPE | SOURCE |
| SIZE | ARRAY |
| SPREAD | SOURCE |
| TRANSFER | SOURCE |
| TRANSPOSE | MATRIX |
| UBOUND | ARRAY |
| UNPACK | VECTOR, FIELD |
===============================================================
The intrinsic functions shown in table 13.2 have a polymorphic result
if and only if the specified argument is polymorphic. Where the
result is specified to have the same type and type parameters as the
argument specified in table 13.2, the result has the same dynamic
type as the specified argument. If the specified argument is
unlimited polymorphic the result is unlimited polymorphic; otherwise
it has the same declared type as the specified argument. If another
argument is required to have the same type as the specified argument,
it shall be polymorphic if and only if the specified argument is
polymorphic, and have the same dynamic type as the specified
argument. If the specified argument is unlimited polymorphic, the
other argument shall also be unlimited polymorphic; otherwise, it
shall have the same declared type as the specified argument.
Table 13.2: Polymorphic intrinsic function results
------------------------------------------------
| Function name | Argument that determines |
| | result characteristics |
------------------------------------------------
| CSHIFT | ARRAY |
| EOSHIFT | ARRAY |
| MERGE | TSOURCE |
| PACK | ARRAY |
| RESHAPE | SOURCE |
| SPREAD | SOURCE |
| TRANSPOSE | MATRIX |
| UNPACK | VECTOR |
================================================
SUBMITTED BY: Rob James
HISTORY: 05-138 m171 Submitted - contained the questions/answers
05-138r1 m171 Contained the edits, passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0052
TITLE: ADVANCE= specifier in child data transfer statements
KEYWORDS: ADVANCE=, UDDTIO, data transfer
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot
QUESTION:
The appearance of the ADVANCE= specifier in a child data transfer
statement is not prohibited, but such an appearance is meaningless.
9.5.3 of Fortran 2003 states that the file is positioned after data
transfer only if the statement is not a child data transfer. The
appearance of the ADVANCE= specifier in such a statement would seem to
serve only to confuse people maintaining a program that contains it.
Was it intended that the ADVANCE= specifier should be allowed to
appear in a child data transfer statement?
ANSWER:
Yes, it was intended that the ADVANCE= specifier should be allowed to
appear in a child data transfer statement. Such a specifier has no
effect. Note that a user defined derived type I/O routine can be
called explicitly by the user, and in that case, the I/O statements
therein are not child data transfer statements.
EDITS: None
SUBMITTED BY: Rob James
HISTORY: 05-143 m171 Submitted
05-143r1 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
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. C589, p. 98 states "If a common-block-object is
of a derived type, it shall be a sequence type (4.5.1) or a
type with the BIND attribute and it shall have no default
initialization."
It also affects whether the types are extensible. 4.5.6 states
"A nonsequence derived type that does not have the BIND attribute is
an extensible type."
2. 15.2.2 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. Yes, it was intended that these types have the BIND attribute.
An edit makes this clear.
2. A user-defined derived type with the BIND attribute is permitted
to have private components.
DISCUSSION:
1. It was intended that the behaviour of these types be similar to
that of user-declared derived types in all respects except that
they interoperate with C pointer types rather than C struct types.
As well as the two cases cited in the question, there are special
conditions in a pointer assignment statement (7.4.2) if either the
pointer or the target has the BIND attribute. Also, there is a
restriction on types with the BIND attribute in a SELECT TYPE
statement (8.1.5).
2. The rules for the interoperability of a C struct type with a
Fortran derived type are less restrictive than the rules in
4.5.1.3 that determine whether two separately declared Fortran
types, both with the BIND attribute, are the same. For the types
to be the same, the names of corresponding components must agree and
all components must be public. It follows that two types may be
different although they both interoperate with the same C struct
type.
EDITS:
Page and line numbers refer to 04-007.
[397:3] Subclause 15.2.2. At the end of the first paragraph add
"Each has the BIND attribute but is not interoperable with any C
struct type."
SUBMITTED BY: John Reid
HISTORY: 05-151 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0054
TITLE: Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT
KEYWORDS: denormal, intrinsic, EXPONENT, FRACTION, SET_EXPONENT
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
What results do EXPONENT, FRACTION, and SET_EXPONENT return if
the value of X is denormal?
If a denorm is loaded into the cpu in extended precision, it
becomes a normal value with changed fractional and exponent parts.
Which of these values should be taken?
In the definition of EXPONENT, the words 'of the model representation
for the value of X' appear; but in the definition of FRACTION and
SET_EXPONENT, the words are 'for the model representation of X'.
Was this difference intended?
ANSWER:
In all three cases, the intention was to treat the value as if it
were held according to the model in 13.14 with the same radix b,
but with an expanded exponent range. This is why the words 'for the
value of X' were used in EXPONENT. It has to be this way for a
denormal value since otherwise it does not lie within the model.
Edits are provided to make the intention clear.
DISCUSSION:
This interpretation is satisfactory from a mathematical point of
view since the values of EXPONENT(X) and EXPONENT(DBLE(X)) will
be the same when X is of type default real and has a denormal value.
Similar properties holds for the other two functions.
EDITS:
Page and line numbers refer to J3/04-007.
[316:5-6] Subclause 13.7.37, Result Value, lines 1-2. Replace
"model ... X" by "representation for the value of X in the model
(13.4) that has the radix of X but no limits on exponent values".
[317:8] Subclause 13.7.40, Result Value, line 2. Replace
"model ... X" by "representation for the value of X in the model
that has the radix of X but no limits on exponent values".
[351:5] Subclause 13.7.107, Result Value, line 2. Replace
"model ... X" by "representation for the value of X in the model
that has the radix of X but no limits on exponent values".
SUBMITTED BY: John Reid
HISTORY: 05-152 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------
NUMBER: F03/0055
TITLE: Denormal inputs to SPACING and RRSPACING
KEYWORDS: denormal, intrinsic, SPACING, RRSPACING
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
What results do SPACING and RRSPACING return if the value of X lies
outside the model of 13.4, in particular if it is denormal?
In the definition of EXPONENT, the words 'of the model representation
for the value of X' appear; but in the definition of SPACING and
RRSPACING, the words are 'for the model representation of X'.
Was this difference intended? Is the intention to indicate that for
SPACING and RRSPACING, the model is that of all reals with the same
kind type parameter value as X?
In the IEEE model, the spacing between any two adjacent denorms is
equal to the smallest denorm. Is it intended that this value be
returned by SPACING?
ANSWER:
The informal description refers to 'model numbers near the argument
value', but the text does not reflect this. Edits are provided to
correct this.
Yes, the difference was intended. In both models, the lower
bound on the exponent has a profound effect on the spacing of
tiny values, so it is important that it be taken into account.
It was intended to refer to the model for all the reals with the
same kind type parameter value as X. Here is it the model of 13.4
that is involved, as the words in 13.4 make clear. If the argument
value is a positive denorm, the model numbers near it are
TINY(X) and 0. Their spacing is TINY(X).
Edits are provided to make this intention clear.
EDITS:
Page and line numbers refer to J3/04-007.
[347:22] Subclause 13.7.100, Result Value, line 2. Replace
"the model representation of X." by "the value nearest to X in the
model for real values whose kind type parameter is that of X; if
there are two such values, the value of greater absolute value is
taken."
[353:9] Subclause 13.7.113, Result Value, line 2. Replace
"the model representation of X." by "the value nearest to X in the
model for real values whose kind type parameter is that of X; if
there are two such values, the value of greater absolute value is
taken."
SUBMITTED BY: John Reid
HISTORY: 05-153 m171 Passed by J3 meeting
05-170 m171 Passed by J3 letter ballot #11
----------------------------------------------------------------------