(j3.2006) Interp letter ballot #25
Van Snyder
Van.Snyder
Wed May 9 20:12:33 EDT 2012
Enclosed in the next letter ballot on Fortran interpretations.
The rules by which we operate say:
o J3 votes on the answer at a J3 meeting; a simple majority
vote marks the answer as "passed by J3 meeting".
o Between J3 meetings the chair of /interp sends a J3 letter
ballot to J3 to approve interp answers that have been "passed
by J3 meeting". The letter ballot runs for 30 days. Not
voting on three of four consecutive J3 letter ballots is
grounds to terminate J3 membership. An interp answer passes
by a 2/3rds vote; a no vote must be accompanied by an
explanation of the changes necessary to change the member's
vote to yes.
J3/interp reserves the right to recall an interp answer for
more study even if the answer passes.
43 Fortran interpretations are currently "Passed by J3 meeting" after
J3 meeting #197. This is the letter ballot phase to go from "Passed
by J3 meeting" to "Passed by J3 letter ballot".
The following Fortran interpretations are being balloted:
Yes No Number Title
-Y- --- F03/0017 Dummy procedure pointers and PRESENT
-Y- --- F03/0018 Multiple identical specific procedures in
type-bound generic interfaces
-Y- --- F03/0019 Multiple identical specific procedures in
generic interface blocks
-Y- --- F03/0021 What kind of token is a stop code?
-Y- --- F03/0046 Unlimited polymorphic pointers in
common blocks
-Y- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR
-Y- --- F03/0065 Relational equivalence
--- -N- F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine
One of the reasons given for not needing to add interval
arithmetic to the work plan for 2003 was that the effect
could be provided using the IEEE facilities. If one writes
CALL IEEE_SET_ROUNDING_MODE(IEEE_DOWN)
V%LOW_BOUND = X * Y
CALL IEEE_SET_ROUNDING_MODE(IEEE_UP)
V%HIGH_BOUND = X * Y
perhaps naively hoping that the processor will actually
round in the specified ways and produce different results
for the low and high bounds, it would be a nasty surprise
to find that in fact the values are always identical.
-Y- --- F03/0096 Can a read statement change the unit value?
--- -N- F03/0103 Restrictions on dummy arguments not present for
polymorphic type or parameterized derived type
I agree that the answer correctly handles the case of
length type parameters (Q2), but it appears not to have
addressed the question of polymorphism (Q1).
-Y- --- F03/0116 indistinguishable specifics for a generic
interface with use association
-Y- --- F03/0118 Are lower bounds of assumed-shape arrays assumed?
-Y- --- F03/0120 When are parameterized sequence types the same
type?
--- -N- F03/0121 Precise FP semantics of the REAL intrinsic
The answer to this interpretation is inconsistent with
13.7.1p2, including as amended by F08/0008: "A program shall
not invoke an intrinsic procedure under circumstances where a
value to be assigned to a subroutine argument or returned as a
function result is not representable by objects of the
specified type and type parameters." This interpretation
permits REAL(0.1d0,kind(1.0e0)) to return a value that is not
representable as default real. The meaning of "representable
by objects of the specified type and type parameters" is taken
from 4.1.1p2 ("A type has ... a set of valid values"), 4.1.2p1
("For each type, there is a set of valid values"), and 4.2p1
("A type might be parameterized. In this case, the set of
values... depend on the values of the parameters"). If the
result is not a member of the "set of valid values" (which
depends upon "values of the parameters"), the function cannot
be invoked. The caveat in 7.1.5.2.4p3 that "mathematically
equivalent expressions of numeric type may produce different
computational results" does not include permission to produce
a value that is not a member of the set of valid values for
the type and type parameters of that result.
One of the reasons advanced in discussion for the provided
answer (but not in the text of the final interpretation) was
that it would intolerably slow down programs if the REAL
intrinsic function were to operate as most readers understand
the description in subclause 13.7.138, taken in the light of
13.7.1p2 (as amended by F08/0008), 4.1.1p2, 4.1.2p1 and 4.2p1,
until they are surprised by the present answer. This is
nonsense. The only reason ever to invoke the REAL intrinsic
function with a real argument is to provide a result value of
the specified kind. Appearance of an invocation of the REAL
intrinsic function with a REAL argument is rare (in my 1/3
million line program, it appears twice), and ought not to
cause a measureable performance degradation in a real program
(i.e., one that is a not carefully contrived SPEC benchmark),
even if the semantics are as one would expect from reading the
description of the REAL intrinsic function, taken in the light
of 13.7.1p2 (as amended by F08/0008), 4.1.1p2, 4.2.1p1 and
4.2p1. If it ever is an issue for performance, processors can
provide an option that enables an extension that invalidates
the requirements of 13.7.1p2 (as amended by F08/0008),
4.1.1p2, 4.2.1p1 and 4.2p1, at least to the extent they would
apply to the REAL intrinsic function.
-Y- --- F08/0004 Is TARGET argument of ASSOCIATED a pointer or
nonpointer dummy?
-Y- --- F08/0008 IEEE exceptions for intrinsic functions
-Y- --- F08/0031 PURE INTENT(OUT) finalization
-Y- --- F08/0032 PURE FUNCTION result finalization
-Y- --- F08/0038 Are pointless restrictions on DIM arguments
intended?
-Y- --- F08/0040 MOVE_ALLOC for coarrays
-Y- --- F08/0042 SOURCE= questions
-Y- --- F08/0043 Executing a type-bound procedure on a coindexed
object
-Y- --- F08/0048 Sequence association for coarrays
-Y- --- F08/0054 Requirements for needing an explicit interface
-Y- --- F08/0055 G editing for reals
-Y- --- F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE=
-C- --- F08/0057 Interoperability with empty types
I would put the new constraint before C1501
-C- --- F08/0058 ENTRY point RESULT variable
There's nothing wrong with the interpretation, or the answer
or edits, but it does raise the question whether the RESULT
name of an entry statement is allowed to be the same as a
dummmy argument of the function statement, or an earlier entry
statement. This is probably a question for a different
interp.
-C- --- F08/0059 Auto-targetting requirements
Delete "and" from the edit for [295:16-17], or replace "with"
by "that has"
-Y- --- F08/0060 Procedure pointer assignment with an EXTERNAL target
-C- --- F08/0061 Description of the CONTIGUOUS attribute misworded?
WG5/J3 ought to decide whether to include the suggested
addition to a future standard in 008.
-Y- --- F08/0062 Mixing default initialization with DATA
initialization
-Y- --- F08/0063 G editing to a narrow output field
-Y- --- F08/0064 STATUS of GET_ENVIRONMENT_VARIABLE
-Y- --- F08/0065 Should certain procedures in intrinsic modules be
pure?
-C- --- F08/0066 Are certain expressions with pointer initialization
constant?
", TRANSFER" in the edit for [152:4] should be ", or TRANSFER"
Edit for [152:7+] should be at [152:6+]
-C- --- F08/0067 Passing arrays of extended type objects
Edit would be simpler as "insert 'a polymorphic assumed-size
array or' after 'is'" at [293:4]
--- -N- F08/0068 Pointer association and extended type arrays
"declared type part of that target" is ambiguous. "Declared
type" of what? (Also see F08/0069.) The target or the
pointer? Does "part" include the possibility of a component
having the same declared type (whatever that means)? Although
substantially more wordy, needs to specify that the pointer
becomes associated with the actual argument if the dynamic
type of the actual argument is the same as the declared type
of the pointer, or with the ancestor component of the actual
argument that has the same type as the declared type of the
pointer. If "ancestor component" were reflexive, the
circumlocution would not be needed.
-Y- --- F08/0069 Which part of an effective argument becomes
undefined?
-C- --- F08/0070 Finalization of INTENT(OUT) arguments
Edit should say where it applies, instead of referring to "the
quoted text" in the question (of which there are two), since
the question will not appear in a corrigendum. Specifying the
location of the correction is a bit complicated since it's a
correction to a correction in a corrigendum. Also, the second
quoted text [12.5.2.4p17] says "only the part of the effective
argument..." when it ought to say "only the ancestor
component...." Maybe that's the subject for a different
interp.
-C- --- F08/0071 Vector subscript target
If the additional suggested edits are not put forward for
inclusion in a corrigendum, WG5/J3 ought to decide whether to
include them in 008.
-Y- --- F08/0072 Final subroutines with corank
-Y- --- F08/0073 Polymorphic auto-targetting
More information about the J3
mailing list