(j3.2006) J3 08-141 Fortran interp letter ballot #16 - due 11-Apr-2008
Whitlock, Stan
stan.whitlock
Fri Mar 7 22:58:04 EST 2008
08-141
To: J3 Members
From: Stan Whitlock
Subject: J3 Fortran interp letter ballot #16 - due 11-Apr-2008
Date: 7-Mar-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.
7 Fortran 2003 interpretations are currently "Passed by J3 meeting"
after J3 meeting #183. 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/0099 Clause 16 does not account for volatile
variable
--- --- F03/0102 Evaluation of bound-expr in data pointer
assignment
--- --- F03/0109 Referencing deferred binding via absent
dummy argument
--- --- F03/0111 Is defined assignment to a vector subscripted
array allowed?
--- --- F03/0112 attributes allowed for dummy arguments in
defined assignments
--- --- F03/0113 Size and uniqueness considerations for ID=
--- --- F03/0114 Inconsistent restrictions on i/o specifiers
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, PDT, Friday, 11-Apr-2008, in order to be counted.
Thanks /Stan
----------------------------------------------------------------------
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."
[421:43] In 16.5.5 list item (26) change "becomes" to "might become".
[423:28+] In 16.5.6 after the last list item insert a new list item
"(19) 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
08-133r1 m183 Failed letter ballot #15 08-101
08-137 m183 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0102
TITLE: Evaluation of bound-expr in data pointer assignment
KEYWORDS: pointer, pointer assignment, bounds, expression
DEFECT TYPE: Clarification
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:
This program does not conform to the Fortran Standard.
The assertion that there are no rules about pointer association status
is false because changes in pointer association status necessarily
cause changes in definition status, as explained in the opening
paragraph of "16.4.2 Pointer association status" which states
"If a pointer is associated with a target, the definition status
of the pointer is either defined or undefined, depending on the
definition status of the target."
The reference to F1(PTR,TAR1,1,1) executes the pointer assignment
PTR(I:J,I:J)=>ARR; this causes its actual argument PTR to become
undefined (using the quoted rule from 16.4.2).
In 7.1.8 paragraph 3, it says
"If a function reference causes definition or undefinition of
an actual argument of the function, that argument or any
associated entities shall not appear elsewhere in the same
statement."
However, PTR appears elsewhere in that statement (as the base object
of the variable in the assignment), violating this requirement.
Therefore the program is not standard-conforming.
EDITS:
None.
NOTE:
This would be clearer if the undefinition case were also added to the
list of "Events that cause variables to become undefined" in clause
16, e.g.
"(n) When a pointer becomes associated with a target that is
undefined, the pointer becomes undefined."
This is recommended for a future revision of the Standard.
SUBMITTED BY: Jim Xia
HISTORY: 07-297r1 m182 F03/0102 Submitted
07-297r2 m182 Passed by J3 meeting
08-133r1 m183 Failed J3 letter ballot
08-135 m183 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.
The same flaw is present for procedure pointer component invocation.
EDITS:
Add new items to the second list in 12.4.1.6, [273:12+]
"(11) It shall not be supplied as the <data-ref> in a
<procedure-designator>.
(12) It shall not be supplied as the <variable> in a
<proc-component-ref>."
SUBMITTED BY: Van Snyder
HISTORY: 07-338 m182 F03/0109 Submitted; Passed by J3 meeting
08-133r1 m183 Failed J3 letter ballot
08-136 m183 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0111
TITLE: Is defined assignment to a vector subscripted array allowed?
KEYWORDS: defined assignment, vector-valued subscripts, elemental
DEFECT TYPE: Clarification
STATUS: Passed by J3 meeting
QUESTION: Is the assignment statement in subroutine cg1018 standard
conforming?
I does an elemental defined assignment to an array with a vector
valued subscript. Several compilers reject this assignment,
claiming that an INTENT(OUT) argument can't be associated with
a vector-valued actual argument.
According to 142:6-7, this is a defined elemental assignment.
Lines 26 to 30 of 142 are
"The interpretation of a defined assignment is provided by the
subroutine that defines it.
If the defined assignment is an elemental assignment and the variable
in the assignment is an array, the defined assignment is performed
element-by-element, in any order, on corresponding elements of
variable and expr."
The first line looks like a general definition of defined assignment
and the second line looks like a qualification for the specific case
of elemental assignment. The qualification has to mean that the
assignments are performed on an element-by-element basis and this
surely must mean that the statement is processed as if it were
expanded into something like
TLA1L(7) = UDA1R(7)
TLA1L(1) = UDA1R(1)
TLA1L(3) = UDA1R(3)
...
and then the assignment subroutine is invoked on an
element-by-element basis following the rules in chapter 12.
Page 140, lines 4-5 have essentially identical words for intrinsic
assignment and intrinsic assignment to a vector valued array,
including derived type arrays, is allowed (if not many-to-one).
The processors that reject the test program apparently interpret the
assignment as
Call U_TO_T( TLA1L(NFV1), (UDA1R))
without doing the assignment on an element-by-element basis.
If that interpretation is correct, then we have the unusual situation
where
TLA1L(NFV1) = TLA1L
is standard conforming if the assignment is intrinsic and non-standard
if the assignment is defined.
MODULE c_TESTS
integer, save :: nfv1(10) = [1,2,3,4,5,6,7,8,9,10]
TYPE UNSEQ
REAL R
END TYPE UNSEQ
TYPE SEQ
sequence
REAL R
END TYPE SEQ
INTERFACE ASSIGNMENT(=)
MODULE PROCEDURE U_TO_T
END INTERFACE ASSIGNMENT(=)
CONTAINS
ELEMENTAL PURE SUBROUTINE U_TO_T(T,U)
TYPE(SEQ),INTENT(IN) :: U
TYPE(UNSEQ), INTENT(OUT) :: T
T%R = U%R
END SUBROUTINE U_TO_T
SUBROUTINE CG1018(TLA1L,UDA1R)
TYPE(UNSEQ) TLA1L(10)
TYPE(SEQ) UDA1R(10)
TLA1L(NFV1) = UDA1R !???????
END SUBROUTINE
END MODULE c_TESTS
ANSWER:
This is not standard conforming. According to [271:3-5]
If the actual argument is an array section having a vector subscript,
the dummy argument is not definable and shall not have the INTENT
(OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS attributes.
EDITS:
None
SUBMITTED BY: Dick Hendrickson
HISTORY: 08-104 m183 F03/0111 Submitted
08-104r1 m183 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0112
TITLE: attributes allowed for dummy arguments in defined assignments
KEYWORDS: defined assignment, dummy argument, attributes
DEFECT TYPE: Clarification
STATUS: Passed by J3 ballot
DISCUSSION:
It seems the standard is quite loose in allowing various attributes
declared for the dummy arguments used in a defined assignment
(7.4.1.4). In particular, attributes such as POINTER and ALLOCATABLE
can be declared for dummy arguments in the defined assignment.
However the interpretations on their declarations need to be
clarified.
Consider the follow subroutines (assuming a derived type DT already
defined)
1. POINTER/ALLOCATABLE on the second dummy argument
interface ASSIGNMENT (=)
subroutine defAssgn1 (dt1, dt2)
type(DT), intent(out) :: dt1
type(DT), POINTER, intent(in) :: dt2
end subroutine
end interface
In 12.3.2.1.2 [263:10-12], the standard says the following
"A defined assignment is treated as a reference to the subroutine,
with the left-hand side as the first argument and the right-hand
side enclosed in parentheses as the second argument."
This statement seems to prohibit the use of subroutine defAssgn1
for defined assignment since a pointer enclosed in parentheses
refers to its associated target not the pointer itself, as
indicated by rules in 7.1.4.1 [123:39-124:3].
2. POINTER/ALLOCATABLE on the first dummy argument
interface ASSIGNMENT (=)
subroutine defAssgn2 (dt1, dt2)
type(DT), POINTER, intent(out) :: dt1
type(DT), intent(in) :: dt2
end subroutine
end interface
There are no rules in the standard disallow this declaration.
However the use of POINTER/ALLOCATABLE attributes on the first
dummy argument is very doubtful. Since POINTER/ALLOCATABLE
attributes don't disambiguate generic declarations(16.2.3), their
use will prevent the normal declarations of defined assignments,
wherein dt1 is declared without POINTER or ALLOCATABLE attribute.
QUESTIONS:
1. Are POINTER and ALLOCATABLE attributes allowed for the second
dummy argument in defined assignment?
2. Are POINTER and ALLOCATABLE attributes allowed for the first
dummy argument in defined assignment?
ANSWER:
Yes to both questions. The standard places very few restrictions on
the arguments to defined assignment subroutines: [363:6...]
Each of these subroutines shall have exactly two dummy arguments.
Each argument shall be nonoptional. The first argument shall have
INTENT (OUT) or INTENT (INOUT) and the second argument shall have
INTENT (IN). ...
Preventing the first argument from having the POINTER
attribute violates F90. Such a restriction for the second argument
has no effect since the right argument is treated as an expression
enclosed in parentheses which would have neither attribute.
EDITS:
None
NOTE:
A future standard should disallow the POINTER and ALLOCATABLE
attributes on the second argument to defined assignment subroutines.
SUBMITTED BY: Jim Xia
HISTORY: 08-120 m183 F03/0112 Submitted
08-120r1 m183 Create answer
08-120r2 m183 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0113
TITLE: Size and uniqueness considerations for ID=
KEYWORDS: asynchronous I/O, ID=, size
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
The ID= specifier returns an identifier (or "handle") for an async
i/o request. Must this fit inside the smallest integer kind
supported by the processor?
Consider:
Integer(Selected_Int_Kind(1)) x(1000)
Character(80) :: test(1000) = (/ ... /)
...
Do i=1,1000
Write (17,'(a)',Asynchronous='Yes',Id=x(i)) test(i)
End Do
...
Do i=1,1000
Wait (17,Id=x(i))
End Do
X is only guaranteed to have approximately 20 values available,
and in practice will probably only have 256 such values, so
we are certainly not going to have 1000 unique handles.
Without loss of generality, suppose that one such duplicate value
is 4. After WAIT(17,ID=4), the async i/o request with ID 4
is no longer pending. This means that the subsequent WAIT(17,ID=4)
is not conforming to the standard since it requires that the ID=
value is one that is pending.
(1) Is the processor permitted to require a minimum size for ID=
(e.g. such as default integer)?
Clearly 1000 values do not fit into a 256-valued object, but apart
from that,
(2) Is the processor required to produce unique ID= values for
each multiple asynchronous i/o operation?
One might conjecture that if the processor returned ID=4 for
two or more async i/o requests on the same unit, the first WAIT
for ID=4 would wait for the first such async i/o request and the
second one would wait for the second such async i/o request.
(3) Does WAIT-ing on an ID= value wait for all async i/o operations
that have that as the handle, or are these queued up?
Unlike other i/o-related specifiers, there does not seem to be any
constraint on the value returned for ID= (such as being non-zero
or non-negative). In the case of the i/o being completed
synchronously, there does not appear to be any way of returning
a "non-handle" to the user program (one might have conjectured that
zero was not a handle, but this is not supported by the text of
the standard).
(4) Was there intended to be a "non-handle" return for ID=?
DISCUSSION:
It is understood that resource considerations may limit the number
of outstanding asynchronous i/o requests, but 19 (the limit implied
by the minimum-size integer that follows the model in c13) seems
awfully small; for that matter 256 seems pretty small for todays
operating systems.
ANSWER:
(1) Yes, the standard should require the ID= specifier to be default
integer or bigger. An edit is provided.
(2) Yes, all pending data transfer operation identifiers on a
particular unit are required to be unique. An edit is provided
to clarify this.
(3) ID= values are required to be unique, so this question does not
arise.
(4) Yes, the value zero should not be a handle but an indication the
request was completed synchronously. An edit is provided to add
this.
EDITS:
In 9.5.1 Control information list,
[187:2] "ID = <scalar-int-variable>" -> "ID = <id-variable>"
[187:10+] Insert new BNF rule and constraint
"R913a <id-variable> <<is>> <scalar-int-variable>
C908a (R913a) <scalar-int-variable> shall be have a decimal range
no smaller than that of default integer."
{Require default integer or larger.}
In 9.5.1.8 ID= specifier in a data transfer statement
[190:17] Change "This value" to
"If this value is zero, the data transfer operation has been
completed. A nonzero value"
{Zero = "it was done synchronously already" value.}
[190:18] After "operation." insert
"This identifier is different from the identifier of any other
pending data transfer operation for this unit."
{Require uniqueness.}
[206:18] Before "the identifier" insert "zero or".
[206:20] After "operation" insert ", if any,".
{Make ID=zero do nothing in WAIT.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 08-122 m183 F03/0113 Submitted
08-122r1 m183 Draft answer
08-122r2 m183 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0114
TITLE: Inconsistent restrictions on i/o specifiers
KEYWORDS: I/O specifier, default logical
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
All of the i/o specifiers that return INTEGER values permit any kind
of integer to be used, even though this is likely to cause problems
with small integers. But all of the i/o specifiers that return
LOGICAL values require "full-size" (default) logical variables, even
though every kind of LOGICAL can represent every LOGICAL value,
viz .TRUE. and .FALSE..
Should these be consistent, i.e. should every kind of LOGICAL be
allowed for EXIST=, NAMED=, OPENED=, and PENDING=?
ANSWER:
Yes, these should have been consistent. Edits are provided.
EDITS:
Replace every occurrence of \si{default-logical-variable} in clause 9
with \si{logical-variable}.
Delete the BNF definition of and constraint for
\si{default-logical-variable} in clause 6.
SUBMITTED BY: Malcolm Cohen
HISTORY: 08-123 m183 F03/0114 Submitted
08-123r1 m183 make answer YES; Passed by J3 meeting
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080307/87e11eae/attachment-0001.html
More information about the J3
mailing list