(j3.2006) (SC22WG5.5332) J3 Fortran interp letter ballot #31 revised - due 6-Oct-2014
Whitlock, Stan
stan.whitlock
Thu Sep 11 23:19:17 EDT 2014
J3/14-233r1
To: J3 Members
From: Stan Whitlock
Subject: J3 Fortran interp letter ballot #31 revised - due 6-Oct-2014
Date: 11-Sep-2014
I was mistaken about the interps passed at meeting #204: only 5
interps were passed not 7. These two interps:
F08/0110 Interdependence of specifier values in input/output
statements
F08/0111 Undefinition
did not pass the J3 meeting so I am removing them from this letter
ballot #31. The ballot is still due 6-Oct-2014. My apologies for
the misunderstanding.
Enclosed in the next letter ballot on Fortran interpretations.
The rules for interpretation handling 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.
5 Fortran interpretations are currently "Passed by J3 meeting" after
J3 meeting #204. 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
--- --- F08/0108 ultimate components and coarrays
--- --- F08/0109 LOCK_TYPE and unlimited polymorphic
--- --- F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
--- --- F08/0113 Specifiers in image control statements
--- --- F08/0114 Can LOCK_TYPE components have the POINTER attribute?
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, Monday, 6-Oct-2014, in order to be counted.
Thanks /Stan
------------------------------------------------------------------------
NUMBER: F08/0108
TITLE: ultimate components and coarrays
KEYWORD: ultimate components, coarrays
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTIONS:
1. Is the declaration of V permitted:
type :: one
real, allocatable :: C[:]
end type one
type :: two
type(one), allocatable :: A
end type two
type(two), pointer :: V(:)
2. Is the declaration of X permitted:
type :: three
real :: C
end type three
type :: four
type(three), allocatable :: A[:]
end type four
type(four) :: X
ANSWERS:
1. Type two is not conforming, because the entity A has a coarray
ultimate component and C525 requires such an entity to be a
nonpointer nonallocatable scalar. Therefore the declaration of V
is not permitted.
2. X satisfies C525, so declaration of X is permitted. X has an
ultimate (allocatable) coarray component (A[:]), and therefore
acording to C526 must be a dummy argument or have the ALLOCATABLE
or SAVE attribute.
EDITS:
None.
SUBMITTED BY: Van Snyder
HISTORY: 14-163 m204 F08/0108 submitted
14-163r1 m204 Fixed examples in questions, revised
answer - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0109
TITLE: LOCK_TYPE and unlimited polymorphic
KEYWORD: LOCK_TYPE, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is
available.
Q1. Is allocation of X%C permitted?
TYPE t
TYPE(LOCK_TYPE),ALLOCATABLE :: c
END TYPE
TYPE(t) :: x[*],y[*]
ALLOCATE(y%c)
ALLOCATE(x%c,SOURCE=y%c)
Q2. Is allocation of C permitted?
class(*), pointer :: C
type(lock_type), intent(in) :: L[*]
allocate ( C, source=L )
Q3. Is allocation of C permitted?
class(*), pointer :: C
allocate ( LOCK_TYPE :: C )
Q4. Is pointer assignment to C permitted?
class(*), pointer :: C
type(lock_type), intent(in), target :: L[*]
c => L
Q5. Is this ALLOCATE statement conforming?
CLASS(*),ALLOCATABLE :: C[:]
TYPE(LOCK_TYPE) :: X
ALLOCATE(C,MOLD=X)
ANSWER:
A1. Allocation of X%C is not intended to be allowed. An edit is
supplied to correct the requirements on allocation of LOCK_TYPE.
A2. Allocation of C is not intended to be allowed. An edit is
supplied to correct the requirements on allocation of LOCK_TYPE.
A3. This allocation of C is permitted.
A4. Pointer assignment to C is permitted.
A5. This statement was intended to be permitted. An edit is supplied
to correct the requirements.
EDITS:
[6:7+] After definition 1.3.33.2 parent component, insert new term
"1.3.33.2a
potential subobject component
nonpointer component, or potential subobject component of a
nonpointer component (4.5.1)".
[127:8-9] 6.7.1.1 Syntax, C643,
Change "C_PTR," to "C_PTR or"
Delete ", LOCK_TYPE ... LOCK_TYPE".
[127:9+] Insert new constraint
"C643a (R627) If SOURCE= appears, the declared type of <source-expr>
shall not be LOCK_TYPE or have a potential subobject
component of type LOCK_TYPE."
[127:18-19] 6.7.1.1, p4,
"If" -> "If an ALLOCATE statement has a SOURCE= specifier and an",
{There is no problem with MOLD=. "subcomponent" works ok here because
we have an object not a type.}
SUBMITTED BY: Van Snyder
HISTORY: 14-164 m204 F08/0109 submitted
14-164r3 m204 As amended, passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0112
TITLE: STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
KEYWORDS: STAT=, ERRMSG=, ALLOCATE, DEALLOCATE
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider
CHARACTER(80) text(0:100), msg
INTEGER stat,istat(0:80)
REAL,ALLOCATABLE :: x(:),y(:,:)
...
ALLOCATE(x(10),STAT=stat,ERRMSG=text(stat)) ! A
DEALLOCATE(x,STAT=stat,ERRMSG=text(stat)) ! B
msg = ''
ALLOCATE(y(999999,999999),STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! C
msg = ''
DEALLOCATE(x,STAT=istat(LEN_TRIM(msg)),ERRMSG=msg) ! D
In each of the statements labelled A-D, there is a dependency between
the STAT= specifier and the ERRMSG= specifier (from STAT= to ERRMSG=
in A and B, and from ERRMSG= to STAT in C and D). There appears to be
no prohibition against this (though there are many prohibitions
against other dependencies in ALLOCATE and DEALLOCATE).
Are all these examples conforming, and if so, is the dependent
variable referenced with the value of the other variable at the
beginning of execution of the statement or at the end of execution of
the statement?
ANSWER:
These are not standard-conforming, as no interpretation is established
for them. An edit is supplied to clarify this prohibition.
EDITS:
[132:4] 6.7.4 STAT= specifier, p1, append
"The <stat-variable> shall not depend on the value of the
<errmsg-variable>.".
[132:22] 6.7.5 ERRMSG= specifier, p1, append
"The <errmsg-variable> shall not depend on the value of the
<stat-variable>.".
SUBMITTED BY: Malcolm Cohen
HISTORY: 14-208 m204 F08/0112 submitted - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0113
TITLE: Specifiers in image control statements
KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider
CHARACTER(80) text(0:100),msg
INTEGER stat,istat(2)
REAL,ALLOCATABLE :: x(:)
TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*]
LOGICAL acq, aacq(0:80)
...
SYNC ALL(STAT=stat,ERRMSG=text(stat)) ! A
SYNC IMAGES (*,STAT=stat,ERRMSG=text(stat)) ! B
SYNC MEMORY(STAT=stat,ERRMSG=text(stat)) ! C
LOCK(lock,ACQUIRED_LOCK=acq, &
STAT=istat(MERGE(1,2,acq)), &
ERRMSG=text(istat(MERGE(1,2,acq)))) ! D
UNLOCK(lock,STAT=stat,ERRMSG=text(stat)) ! E
LOCK(alock(stat),STAT=stat) ! F
msg = ''
UNLOCK(alock(LEN_TRIM(msg)),STAT=stat, &
ERRMSG=msg) ! G
stat = 13
SYNC IMAGES(stat,STAT=stat) ! H
msg = 'oops'
SYNC IMAGES(LEN_TRIM(msg),STAT=stat, &
ERRMSG=msg) ! I
In each of the statements labelled A-F, there is a dependency between
the STAT= specifier and the ERRMSG= specifier. There appears to be no
prohibition against this.
Additionally, in the LOCK statement (D), there is a dependency between
the ACQUIRED_LOCK= specifier and the STAT= specifier (there is no
dependency between ACQUIRED_LOCK= and ERRMSG= because the former is
only set on successful execution and the latter is only set on an
error condition). There appears to be no restrictions at all on any
dependencies from ACQUIRED_LOCK=.
In the LOCK statement (F), there is a dependency between the STAT=
specifier and the lock variable. Similarly for the UNLOCK (G), there
is a dependency between the lock variable and the ERRMSG= specifier.
In the SYNC IMAGES statement (H), there is a dependency between the
STAT= variable and the image set. In the SYNC IMAGES statement (I),
there is a dependency between the ERRMSG= variable and the image set.
Are all these examples conforming, and if so, is the dependent
variable referenced with the value of the other variable at the
beginning of execution of the statement or at the end of execution of
the statement?
ANSWER:
No interpretation is established and therefore these are not
conforming. An edit is provided to clarify this.
EDITS:
[190:16-] 8.5.4 SYNC IMAGES statement, insert new p1,
"The value of <image-set> shall not depend on the value of
<stat-variable> or <errmsg-variable>.".
[194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1,
"The <lock-variable> shall not depend on the value of
<stat-variable>, <errmsg-variable>, or the
<scalar-logical-variable> in the ACQUIRED_LOCK= specifier.
The <scalar-logical-variable> shall not depend on the
<lock-variable>, <stat-variable>, or <errmsg-variable>.".
[195:2-] 8.5.7 STAT= and ERRMSG= specifiers..., insert new p1,
"The <stat-variable> shall not depend on the value of the
<errmsg-variable>, <lock-variable>, or the
<scalar-logical-variable> in the ACQUIRED_LOCK= specifier.
The <errmsg-variable> shall not depend on the value of the
<stat-variable>, <lock-variable>, or the <scalar-logical-variable>
in the ACQUIRED_LOCK= specifier.".
SUBMITTED BY: Malcolm Cohen
HISTORY: 14-209 m204 F08/0113 submitted - passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F08/0114
TITLE: Can LOCK_TYPE components have the POINTER attribute?
KEYWORD: LOCK_TYPE component, POINTER
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
Assume LOCK_TYPE is accessible from ISO_Fortran_Env.
QUESTION:
The following type definition and variable declaration are permitted by
C1302:
type :: One
type(lock_type), pointer :: L
end type One
type(one), allocatable :: L1[*]
C1302 requires a named variable of LOCK_TYPE to be a coarray. C526
requires a coarray to be allocatable or to have the SAVE attribute.
The following declaration is apparently prohibited because L4 is
not a coarray:
type(lock_type), pointer :: L4
Was it intended that pointer components of type LOCK_TYPE be permitted,
but that named variables of type LOCK_TYPE with the POINTER attribute be
prohibited?
ANSWER:
It was intended that components of type LOCK_TYPE not be permitted to
have the POINTER attribute. Edits are provided to correct this mistake.
EDITS:
[399:18+] 13.8.2.16 LOCK_TYPE, after C1302, insert new constraint
"C1302a A component of type LOCK_TYPE, or that has a nonallocatable
direct component of type LOCK_TYPE, shall not have the
POINTER attribute.".
SUBMITTED BY: Van Snyder
HISTORY: 14-140 m204 F08/0114 submitted
14-140r1 m204 Revised to reverse decision
14-140r2 m204 Passed by J3 meeting
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140912/77f89995/attachment-0001.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 14-233r1 interp LB #31 revised m205 due 6-Oct-2014.txt
Url: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140912/77f89995/attachment-0001.txt
More information about the J3
mailing list