(j3.2006) J3 Fortran interp letter ballot #15 - due 10-Feb-2008
Whitlock, Stan
stan.whitlock
Wed Jan 9 21:43:02 EST 2008
08-xxx
To: J3 Members
From: interp/Stan Whitlock
Subj: J3 Fortran interp letter ballot #15 - due 10-Feb-2008
Date: 8-Jan-2008
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.
14 Fortran 2003 interpretations are currently "Passed by J3 meeting"
after J3 meeting #182. This is the letter ballot phase to go from
"Passed by J3 meeting" to "Passed by J3 letter ballot".
The following Fortran interpretations are being balloted:
Yes No Number Title
--- --- F03/0003 Referencing deferred bindings
--- --- F03/0004 Type-bound procedures and undefined association
status
--- --- F03/0079 Value of decimal exponent for a real zero value
--- --- F03/0080 Formatted output of a negative real zero value
--- --- F03/0099 Clause 16 does not account for volatile variable
--- --- F03/0100 Error in field width for special cases of signed
INFINITY output
--- --- F03/0102 Evaluation of bound-expr in data pointer
assignment
--- --- F03/0103 Restrictions on dummy arguments not present for
polymorphic type or parameterized derived type
--- --- F03/0104 Deallocation and finalization of bounds-remapped
pointers
--- --- F03/0105 SIZE= specifier and UDDTIO
--- --- F03/0106 Inquire by unit inconsistencies
--- --- F03/0107 Are the IEEE_* elemental routines required
--- --- F03/0108 Is IEEE_SUPPORT_NAN consistent with the other
IEEE_SUPPORT functions
--- --- F03/0109 Referencing deferred binding via absent dummy
argument
The text of these interpretations is attached. Each interpretation
starts with a row of "-"s.
Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send only the
above text {not this entire mail message} with any comments to
j3 at j3-fortran.org
by 11:59:59PM, PST, Sunday, 10-Feb-2008, in order to be counted.
Thanks /Stan
----------------------------------------------------------------------
NUMBER: F03/0003
TITLE: Referencing deferred bindings
KEYWORDS: Type-bound procedure, deferred binding
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
I thought that the intent was that it would be
impossible to reference a deferred binding. However, it
doesn't appear to me that this intent was achieved.
Consider the following program (Sorry, but I don't have
any compilers up to syntax-checking this).
module defer
type, abstract :: t
contains
procedure (sub), nopass, deferred :: deferred_proc
end type t
type, extends(t) :: t2
contains
procedure :: deferred_proc => sub2
end type t2
contains
subroutine sub
write (*,*) 'Hello.'
end subroutine sub
subroutine sub2
write (*,*) 'Goodbye.'
end subroutine sub2
end module defer
program p
use defer
class(t), pointer :: x
nullify(x)
call x%deferred_proc
end program p
Is this a valid program? If not, what restriction of the
standard does it violate?
Note that x%deferred_proc does not require the value of x (4.5.7)
and thus is not a reference to x (2.5.6). Therefore, [83:23-24]
does not prohibit this. Nor is it clear that there is an intent
to prohibit invocation of type-bound procedures for disassociated
pointer objects; except in the case of deferred bindings, this
seems well-defined and potentially useful.
Because x is disassociated, its dynamic type is the same
as its declared type, thus making the interpretation of
x%nondeferred_proc reasonably clear.
ANSWER:
No, this was not intended to be a valid program. A type-bound procedure
may not be invoked through an undefined pointer, a disassociated
pointer,
or an unallocated allocatable variable. An edit is supplied to clarify
this situation. The same answer and edit also apply to F03/0004.
EDITS:
Insert after [04-007: 266: 24] ([07-007r3: 309: 11]):
"The <data-ref> shall not be an undefined pointer, a disassociated
pointer, or an unallocated allocatable variable."
Note: this is the same edit as interp F03/0004.
SUBMITTED BY: Richard Maine
HISTORY: 04-322 m169 F03/0003 Submitted
04-322r1 m169 Passed by J3 meeting
04-418r1 m170 Subsumed by interp F03/0004
05-180 m172 Failed WG5 ballot N1617 - the edit is
subsumed by F03/0004
07-280 m182 Revised
07-280r1 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0004
TITLE: Type-bound procedures and undefined association status
KEYWORDS: Type-bound procedure, dynamic type
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
It appears that the dynamic type is undefined for a pointer with
undefined association status. This impacts type-bound
procedures. Consider the following program.
module undefined
type :: t
contains
procedure, nopass :: nondeferred_proc => sub
end type t
type, extends(t) :: t2
contains
procedure, nopass :: nondeferred_proc => sub2
end type t2
contains
subroutine sub
write (*,*) 'Hello.'
end subroutine sub
subroutine sub2
write (*,*) 'Goodbye.'
end subroutine sub2
end module undefined
program p
use undefined
class(t), pointer :: x
call x%nondeferred_proc
end program p
Is this a valid program? If not, what restriction of the
standard does it violate? If so, what does it print.
Note that x%nondeferred_proc does not require the value of x (4.5.7)
and thus is not a reference to x (2.5.6). Therefore, [83:23-24]
does not prohibit this.
If x were disassociated, its dynamic type would be t and the
interpretation of this would be reasonably clear.
However, the standard does not appear to specify the dynamic type
of x when its association status is undefined. Nor can I find
any prohibition that applies to this case.
ANSWER:
No, the program is not valid, because the standard does not establish
an interpretation of it. An edit is supplied to clarify this.
Furthermore, the case with a disassociated pointer was not intended to
be valid. An edit is supplied to correct this oversight.
DISCUSSION:
Access to object-bound procedures (a.k.a. procedure pointer
components) always require there to be an object. Access to
type-bound procedures of an object was intended to require this too,
but the effect of the NOPASS attribute on this was overlooked.
EDITS:
All edits refer to 04-007.
Insert after [266:24]:
"The <data-ref> shall not be an undefined pointer, a disassociated
pointer, or an unallocated allocatable variable."
Note: this is the same edit as interp F03/0003.
SUBMITTED BY: Richard Maine
HISTORY: 04-323 m169 F03/0004 Submitted
04-323r1 m169 Passed by J3 meeting
04-418r1 m170 Passed J3 letter ballot #9
05-180 m172 Failed WG5 ballot N1617
07-337 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0079
TITLE: Value of decimal exponent for a real zero value
KEYWORDS: Data edit descriptors, Numeric editing, decimal exponent,
zero value
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
In formatted output, what is the value of the
decimal exponent produced for a real zero value
under the D, E, EN, ES, and G edit descriptors?
ANSWER:
In such a case, the decimal exponent should have
the value zero whether or not a nonzero scale factor
is in effect. Edits are supplied to make this clear.
DISCUSSION:
The Fortran 2003 standard does not specify what the value of the
decimal exponent of a real zero value should be under formatted
output. Every implementation of which Sun is aware uses the value
zero for the decimal exponent unless a nonzero scale factor is in
effect. Different implementations format real zeros differently under
nonzero scale factors, but the difference is mainly in the form of the
mantissa and not the exponent.
EDITS:
[227:15+] At the end of the numbered list in 10.6.1 "Numeric
editing", add:
"(7) On output of a real zero value, the digits in the
exponent field shall all be zero, whether or not
a nonzero scale factor is in effect."
SUBMITTED BY: Michael Ingrassia
HISTORY: 06-125 m175 F03/0079 Submitted
07-281r2 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0080
TITLE: Formatted output of a negative real zero value
KEYWORDS: formatted output, negative zero, IEEE
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Suppose a Fortran processor's representation of the real zero
value is signed. When a negative real zero value is written
using formatted output, does the Fortran 2003 standard require
the representation of the zero value in the output field to be
prefixed with a minus sign?
ANSWER:
Yes, the negative sign is required to appear in formatted output
of a negative zero value. In subclause 10.6.1, list item (3) at
[227:3-4] says "The representation of a negative internal value
in the field shall be prefixed with a minus sign." For a
processor that distinguishes between positive and negative zero,
there is no exemption for output at [38:1-6]. For the case of
IEEE reals, the IEEE_IS_NEGATIVE function at [375:25] explicitly
says that -0.0 is "negative".
EDITS:
none.
SUBMITTED BY: Michael Ingrassia
HISTORY: 06-126 m175 F03/0080 Submitted
07-282r1 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0099
TITLE: Clause 16 does not account for volatile variable
KEYWORDS: volatile, defined, undefined
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Should the various lists in clause 16 that describe definition and
association be modified to include the effects of volatile variables?
In particular, 16.4.2.1.1 through 16.4.2.1.2 do not mention the fact
that pointer association status can be volatile and change by other
means.
16.5.4 says "all other variables are initially undefined.? Can a
volatile variable be initially defined by other means?
16.5 (26) says volatile variables "become defined", but they also can
become undefined, by other means.
Allocatable volatile variables can become allocated or unallocated by
other means also.
ANSWER:
Yes, the lists in clause 16 should be modified to include the effects of
volatility. In addition, the effects of volatile on pointer objects
are not completely specified in clause 5. The effect on allocatable
objects is not complete in clause 6.
EDITS:
[85:10] In the paragraph between note 5.21 and note 5.22, change
"association status and array bounds" to "association status, dynamic
type and type parameters, and array bounds"
[415:27] Add a new paragraph at the end of 16.4.2.1.4
"The association status of a pointer object with the VOLATILE attribute
may change by means not specified by the program. If the association
status of such an object changes, its array bounds or deferred type
parameters may change. If in addition it is polymorphic, its dynamic
type
and additional type parameters not specified in its declaration may also
change."
[421:42-43] In 16.5.5 Replace list item (26) with (as text, not a list
item)
"In addition, an object with the VOLATILE attribute (5.1.2.16) might
become defined by means not specified by the program."
[423:28+] In 16.5.6 after the last list item insert (as text, not a list
item)
"In addition, an object with the VOLATILE attribute (5.1.2.16) might
become undefined by means not specified by the program."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-269 m181 F03/0099 Submitted
07-269r2 m181 Passed by J3 meeting
07-279/07-321 Failed letter ballot
07-339 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0100
TITLE: Error in field width for special cases of signed INFINITY output
KEYWORDS: formatted output, signed infinity
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Is there an error in the description for the output of a IEEE infinity
with a sign and a field width of 3 or 8?
228:36-37 describes the output for an IEEE infinity and special cases
field widths of 3 and 8. But, the special casing doesn't consider the
possibility of a plus or minus sign in the field. A signed infinity
should be special cased for field widths of 9 and 4. The current text
also fails to take into account the case of <w> = 0, for both Infinity
and NaN values.
ANSWER:
Yes, there is an error in the special cases. Edits are provided to
correctly describe the required field widths for signed infinities.
An edit is also provided to repair the description of the output of
NaN values.
EDITS:
[228:36-37] In the paragraph beginning "For an internal value that is
an IEEE infinity." in 10.6.1.2.1 "F editing" replace the final
sentence with:
'The minimum field width required for output of the form "Inf" is 3 if
no sign is produced, and 4 otherwise. If <w> is greater than zero but
less than the minimum required, the field is filled with asterisks.
The minimum field width for output of the form "Infinity" is 8 if no
sign is produced and 9 otherwise. If <w> is less than the mimimum
required but large enough to produce the form "Inf" then the form
"Inf" is output.'
[229:2] In the last sentence of the paragraph in 10.6.1.2.1 "F
editing" covering the output of NaN values, replace "If <w> is less
than 3" with "If <w> is greater than zero and less than 3".
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-271 m181 F03/0100 Submitted
07-271r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0102
TITLE: Evaluation of bound-expr in data pointer assignment
KEYWORDS: pointer, pointer assignment, bounds, expression
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
DISCUSSION:
Currently there are no rules in 7.4.2.1 to prohibit changing of a
pointer's association status during evaluation of bound expressions
in a data pointer assignment (pointer with either bounds-spec or
bounds-remapping specified). This may lead to ambiguous code with
regard to the evaluation orders between the bound expression and
the data pointer assignment itself. Consider the following code,
integer, target :: tar2(100, 100)
integer, target :: tar1(100)
integer, pointer :: ptr(:,:)
ptr(-2:, f1(ptr, tar1, 1, 1):) => tar2
print*, lbound(ptr)
print*, ubound(ptr)
print*, size(ptr)
contains
function f1(ptr, arr, i, j)
integer :: i, j, f1
integer, pointer :: ptr(:, :)
integer, target :: arr(:)
ptr (i:j, i:j) => arr
f1 = -1
end function
end
In 7.4.1.3 for interpretation of intrinsic assignments, there are rules
explicitly requesting evaluation of all expressions in variable occurred
before the variable is defined [139:14-19]. It appears that data
pointer
assignment should also follow similar rules.
Note the similar problem also exists for evaluating the <data-target> if
it references a function that returns a data pointer.
QUESTION:
(a) Is this program intended to be standard conforming?
(b) If it is standard conforming, then what would it print?
ANSWER:
(a) No, this program is not intended to be standard conforming.
Edits are provided to clarify this.
EDITS:
[04-007:128:6] After "undefinition" insert ", or changes the pointer
association status or allocation status,"
SUBMITTED BY: Jim Xia
HISTORY: 07-297r1 m182 F03/0102 Submitted
07-297r2 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0103
TITLE: Restrictions on dummy arguments not present for polymorphic
type or parameterized derived type
KEYWORDS: dummy argument, present, polymorphic, parameterized derived
type
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
DISCUSSION:
In 12.4.1.6, rules underlying items (7) and (8) (at [04-007:273:7-10])
say
that if a POINTER/ALLOCATABLE optional dummy argument is not present
then
it can not be supplied as an actual argument corresponding to an
optional
nonpointer/non- allocatable dummy argument.
QUESTION:
Should the reasons underlying items (7) and (8) also apply to the
following two situations:
1.) a polymorphic optional dummy argument that is not present
is supplied as an actual argument corresponding to an optional
non-polymorphic dummy argument;
2.) a non-present optional dummy argument of derived type with
an assumed type parameter is supplied as an actual argument
corresponding to an optional dummy argument that does not have
the same assumed type parameter
One of the reasons that these rules should apply is that the non-present
dummy argument might be supplied as the actual argument to a procedure
using a different calling convention (pass-by-descriptor to pass-
by-address).
It appears that the current standard overlooked these two cases. An
edit is supplied to correct this oversight.
ANSWER:
It is intended that these two situations are allowed. In the first
case,
the actual and dummy arguments are required to have the same declared
type, regardless of whether the dummy argument is optional (first
paragraph of subclause 12.4.1.2).
In the second case, the second paragraph of subclause 12.4.1.2 (at
[04-007:269:1-4]) requires the value of the assumed type parameter of
the
(absent) actual argument to have the same value as the non-assumed type
parameter of the (absent) dummy argument. This shouldn't be required.
An
edit is provided to correct this oversight.
EDITS:
Replace the second paragraph of 12.4.1.2 (at [04-007:269:1-4]):
"The type parameter values of the actual argument shall agree with the
corresponding ones of the dummy argument that are not assumed or
deferred
unless
o the dummy argument is not present (12.4.1.6), or
o the actual argument is of type default character and the dummy
argument is not assumed shape."
SUBMITTED BY: Jim Xia
HISTORY: 07-298r1 m182 F03/0103 Submitted
07-298r2 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0104
TITLE: Deallocation and finalization of bounds-remapped pointers
KEYWORDS: deallocate, finalization, bounds-remapping, pointer
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
INTRODUCTION:
Consider the following example assuming a derived type of X is declared
previously and made accessible to the current scoping unit,
type(X), pointer :: a(:), b(:,:)
allocate (a(100))
b(1:10, 1:10) => a
DEALLOCATE (b)
QUESTION:
(a) Is DEALLOCATE (b) in the example intended to be standard
conforming?
(b) If the answer to (a) is yes, and also assume type X has
finalizers of both rank-one and rank-two, then which finalizer
should be invoked by the DEALLOCATE statement.
ANSWER:
(a) Yes, the example is intended to be standard conforming. The
deallocation of pointer b should be executed successfully.
(b) Standard is clear about how the finalizations processed in this
case. In 4.5.5.1, the first step in invoking the appropriate
final subroutine requires a finalizer matching the rank of the
entity being finalized. In this case, object b is being
finalized and therefore the rank-two final subroutine of type X
will be invoked with object b as the actual argument.
EDITS:
None.
SUBMITTED BY: Jim Xia
HISTORY: 07-299 m182 F03/0104 Submitted; Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0105
TITLE: SIZE= specifier and UDDTIO
KEYWORDS: SIZE=, UDDTIO
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
DISCUSSION:
9.5.1.14 [191:21-26] 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 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:
No, this example is not standard conforming. SIZE= specifier is
not allowed in the example presented here. Edits are provided to
correct this oversight.
EDITS:
[188:8+] In 9.5.1 "Control information list", after the list of
constraints, append to the end of the first paragraph
"A SIZE= specifier shall not appear in a parent input statement if
the user-defined derived-type input procedure to be invoked
performs either list-directed or namelist input on the same
unit."
SUBMITTED BY: Jim Xia
HISTORY: 07-302 m182 F03/0105 Submitted
07-302r1 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0106
TITLE: Inquire by unit inconsistencies
KEYWORDS: inquire, unit, not connected
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
There are many things that can be inquired about, such as ACTION
or READ, that are purely file or connection properties. In
some cases, such as ACTION, the specifier description includes
"If there is no connection [the result is] the value UNDEFINED"
or similar words. In other cases, such as READ, there seems
to be a tacit assumption that there is a file connected to the
unit. The descriptions refer to "the file" and don't specify a
result if there is no connection. In most cases, there is a
phrase like "if the processor is unable to determine if the
file ... [the result is] {UNDEFINED, UNKNOWN, -1, etc.}".
Question 1) Are the inquire specifiers DIRECT, ENCODING,
FORMATTED, NAMED, NEXTREC, NUMBER, POS, READ, READWRITE,
SEQUENTIAL, SIZE, STREAM, UNFORMATTED, and WRITE allowed
in an INQUIRE by unit when there is no file connected to the
unit?
Question 2) If so, should the descriptions for the above
specifiers be clarified by adding phrases such as "if there is
no file specified or connected" to the "UNKNOWN" result
descriptions?
ANSWER:
Question 1) Yes. In an inquiry by unit, the specifiers have
little meaning when there is no file connected to the unit.
However, the standard should specify the results.
Question 2) Yes, edits are supplied below.
Note: 9.9.1.15 NAMED= [213:10] needs no edit; the value will be
false if the unit specified by UNIT= is not connected to
a file
EDITS:
9.9.1.8 DIRECT= At [212:15], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.9 ENCODING= At [212:21], after "file" insert "or if the unit
specified by UNIT= is not connected to a file"
9.9.1.12 FORMATTED= At [212:36], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.16 NEXTREC= At [213:16], after "connection" insert "or if the
unit specified by UNIT= is not connected to a file"
9.9.1.17 NUMBER= At [213:21+], insert "If the unit specified by
UNIT= is not connected to a file, the value is the unit specified
by UNIT=."
9.9.1.21 POS= At [214:20], after "conditions" insert "or if the unit
specified by UNIT= is not connected to a file"
9.9.1.23 READ= At [215:2], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.24 READWRITE= At [215:7], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.27 SEQUENTIAL= At [215:26], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.29 SIZE= At [215:34], after "determined" insert "or if the unit
specified by UNIT= is not connected to a file"
9.9.1.30 STREAM= At [216:5], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.31 UNFORMATTED= At [216:10], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
9.9.1.32 WRITE= At [216:15], add to the end of the last sentence
"or if the unit specified by UNIT= is not connected to a file"
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-309 m182 F03/0106 Submitted
07-309r1 m182 Answer based on 07-310; Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0107
TITLE: Are the IEEE_* elemental routines required
KEYWORDS: IEEE, elemental routines
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
The descriptions for all of the IEEE elemental intrinsics listed in
14.9 say something like "shall not be invoked if
IEEE_SUPPORT_DATATYPE(X) is false".
I believe this was to allow a careful programmer to do something
like
if (IEEE_SUPPORT_DATATYPE(x)) then
x = IEEE_SCALB(x,2)
else
x = x*4
endif
and program around partial IEEE support.
But 14.9.2 says that "IEEE_ARITHMETIC contains the following
[routines] for which IEEE_SUPPORT_DATATYPE(X) [is] true"
I'd read that as saying the functions aren't there for cases where
IEEE_SUPPORT_DATATYPE is false. But, then, there is no way to
program around their absence. The example above will fail at load
time because IEEE_SCALB is absent.
If a processor provides the IEEE_ARITHMETIC module must it
provide versions of all of the intrinsics for all of the available
datatypes, including those for which IEEE_SUPPORT_DATATYPE() is false?
ANSWER:
Yes, edits are provided to make this clear.
DISCUSSION: It was intended that the above coding snippet could be
used by a careful programmer to program portably for processors which
have varying degrees of IEEE support. This might require processors to
provide some stub function for each routine and for each non-IEEE
datatype they support. If a program invokes one of the stub routines,
it is a run-time programming error. Nevertheless, a program which
has references to the routines, but doesn't invoke them, must load
and execute.
EDITS:
[370:8-9] Replace
"for reals X and Y for which IEEE_SUPPORT_DATATYPE(X) and
IEEE_SUPPORT_DATATYPE(Y) are true"
with
"for all reals X and Y"
Insert a note at [369:28+]
"The standard requires that code such as
if (IEEE_SUPPORT_DATATYPE(x)) then
x = IEEE_SCALB(x,2)
else
x = x*4
endif
be executable. The elemental functions in the IEEE_ARITHMETIC
module (14.9.2) must exist for all real kinds supported by the
processor, even if IEEE_SUPPORT_DATATYPE returns false for
some kinds. However, if IEEE_SUPPORT_DATATYPE returns false
for a particular kind, these functions must not be invoked
with arguments of that kind. This allows a careful programmer
to write programs that work on processors that do not support
IEEE arithmetic for all real kinds.
The processor might provide stub routines which allow the program
to link and execute, but which will abort if they are invoked."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-312 m182 F03/0107 Submitted
07-312r2 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0108
TITLE: Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT
functions
KEYWORDS: IEEE_SUPPORT_NAN, IEEE support functions
DEFECT TYPE: Clarification
STATUS: Passed by J3 meeting
QUESTION:
The restriction of IEEE_IS_NAN requires that IEEE_SUPPORT_NAN returns
the value true. The restrictions for the similar functions
IEEE_IS_{FINITE, NEGATIVE, and NORMAL} all require that
IEEE_SUPPORT_DATATYPE be true. This is a much stronger restriction.
Should IEEE_SUPPORT_NAN also require that IEEE_SUPPORT_DATATYPE
return true?
ANSWER:
No. The IEEE_SUPPORT_NAN restriction is weaker than requiring
IEEE_SUPPORT_DATATYPE but IEEE_SUPPORT_NAN is sufficient.
IEEE_SUPPORT_DATATYPE is used in IEEE_IS_FINITE, IEEE_IS_NEGATIVE,
and IEEE_IS_NORMAL because there are no IEEE_SUPPORT_* inquiry
functions to query support for finite, negative, or normal.
IEEE_SUPPORT_INF asks about infinities not finites and
IEEE_SUPPORT_DENORMAL only covers denormals and not the other
non-finites (NaNs and Infinities).
EDITS:
None.
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-328 m182 F03/0108 Submitted
07-328r2 m182 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0109
TITLE: Referencing deferred binding via absent dummy argument
KEYWORDS: Type-bound procedure, deferred binding
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
The intent was that it would be impossible to reference a deferred
binding. However, it doesn't appear to me that this intent was
achieved.
Consider the following program
program P
type, abstract :: T
contains
procedure(sub), nopass, deferred :: deferred_proc
end type T
call sub
contains
subroutine Sub ( X )
class(t), optional :: X
call x%deferred_proc
end subroutine Sub
end program P
Is this a valid program? If not, what restriction of the standard does
it
violate?
Since x%deferred_proc has the NOPASS attribute, this does not require
the
value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore,
the first item in the second list in 12.4.1.2 (at [04-007:272:32-33])
does
not prohibit this.
ANSWER:
This was not intended to be a valid program. A type-bound procedure
shall
not be invoked through an absent dummy argument. An edit is supplied to
clarify this situation.
EDITS:
Insert after C1224 in subclause 12.4 (at [04-007: 266: 24]) ([07-007r3:
309: 11]):
"The <data-ref> shall not be an undefined pointer, a disassociated
pointer, an unallocated allocatable variable, or a dummy data object
that
is not present (12.4.1.6)." (This subsumes the edits for F03/0003 and
F03/0004).
SUBMITTED BY: Van Snyder
HISTORY: 07-338 m182 F03/0109 Submitted; Passed by J3 meeting
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080109/6332d7d5/attachment-0001.html
More information about the J3
mailing list