(j3.2006) (SC22WG5.5329) J3/14-233 J3 Fortran interp letter ballot #31 - due 6-Oct-2014

Whitlock, Stan stan.whitlock
Mon Sep 8 03:09:50 EDT 2014


                                                                                   J3/14-233
To:           J3 Members
From:       Stan Whitlock
Subject:   J3 Fortran interp letter ballot #31 - due 6-Oct-2014
Date:        8-Sep-2014

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 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/0110   Interdependence of specifier values in input/output
                               statements
---  ---  F08/0111   Undefinition
---  ---  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/0110
TITLE: Interdependence of specifier values in input/output statements
KEYWORD: specifier, input/output statement
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting

QUESTIONS:

1. Are the following INQUIRE statements permitted?

    LOGICAL :: Exist, Opened
    INQUIRE ( FILE='fred', EXIST=exist )
    INQUIRE ( UNIT=42, OPENED=opened

2. Is the following INQUIRE statement permitted?

    INTEGER :: U
    INTERFACE
      FUNCTION P ( A )
        INTEGER, INTENT(IN) :: A
        INTEGER, POINTER :: P
      END FUNCTION P
    END INTERFACE
    INQUIRE ( FILE='fred', NUMBER=u, POSITION=p(u) )

3. Is the following READ statement permitted?

    INTEGER :: STATS(42)
    NAMELIST /IN/ V
    READ ( *, IN, IOSTAT=STATS(V) )

ANSWERS:

1. According to 9.12p5

  "The value of a specifier in an input/output statement shall not
  depend on the definition or evaluation of any other specifier in the
  <io-control-spec-list> or <inquire-spec-list> in that statement."

the INQUIRE statements are prohibited because the values of the
variables EXIST and OPEN depend upon the values of the FILE= and UNIT=
specifiers, respectively.  They were intended to be permitted.  Edits
are provided to correct this mistake.

2. According to 9.12p6

  "The value of any subscript or substring bound of a variable that
  appears in a specifier in an input/output statement shall not depend
  on any <input-item>, <io-implied-do> <do-variable>, or on the
  definition or evaluation of any other specifier in the
  <io-control-spec> or <inquire-spec> in that statement."

the INQUIRE statement is not prohibited because U is not a subscript or
substring bound.  It was intended to be prohibited.  Edits are provided
to correct this mistake.

3. According to 9.12p5

  "The value of any subscript or substring bound of a variable that
  appears in a specifier in an input/output statement shall not depend
  on any <input-item>, <io-implied-do> <do-variable>, or on the
  definition or evaluation of any other specifier in the
  <io-control-spec> or <inquire-spec> in that statement."

and 9.12p7

  "In a data transfer statement, the variable specified in an IOSTAT=,
  IOMSG=, or SIZE= specifier, if any, shall not be associated with any
  entity in the ... <namelist-group-object-list>...."

and 9.12p8

  "In a data transfer statement, if a variable specified in an IOSTAT=,
  IOMSG=, or SIZE= specifier is an array element reference, its
  subscript values shall not be affected by the data transfer, the
  <io-implied-do> processing, or the definition or evaluation of any
  other specifier in the <io-control-spec-list>."

the READ statement is not prohibited because V does not "depend on any
<input-item>, <io-implied-do> <do-variable>, or on the definition or
evaluation of any other specifier in the <io-control-spec> or
<inquire-spec> in that statement."   Although V is input from namelist,
it is not "the variable specified in an IOSTAT=, IOMSG=, or SIZE=
specifier."  The READ statement was intended to be prohibited.  Edits
are provided to correct this mistake.

EDITS to 10-007r1:

[243:3-4 9.12p5] Within the first sentence, as amended by Corrigendum 2,
replace "input/output" with "data transfer" and delete "or
<inquire-spec-list>", so that the sentence, as amended by Corrigendum
2, becomes

  "The value of a specifier in a data transfer statement shall not
  depend on the evaluation of any other specifier in the
  <io-control-spec-list> in that statement."

If we assume that the UNIT= <file-unit-number>, FILE= <file-name-expr>,
or ID= <scalar-int-expr> in an <inquire-spec-list> are established
before the values of any of the <variable>s are changed, we need not
append

  "The value of a <file-unit-number>, <file-name-expr>, or
  <scalar-int-expr> in an <inquire-spec-list> shall not depend upon the
  definition of any variable in that <inquire-spec-list>."

[243:6, 12-15 9.12p6,8] Replace the paragraphs:

  "In an input/output statement, the value of any argument in a function
  reference that is a <variable>, any subscript, or any substring bound,
 that appears in a specifier in that statement, shall not be affected
  by data transfer or <implied-do> processing caused by that statement,
  or definition or evaluation of any other specifier in the
  <io-control-spec-list> or <inquire-spec-list> in that statement."

SUBMITTED BY: Van Snyder

HISTORY: 14-193    m204  F08/0110 submitted
         14-193r1  m204  Passed by J3 meeting

----------------------------------------------------------------------

NUMBER: F08/0111
TITLE: Undefinition
KEYWORD: undefinition
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting

QUESTIONS:

1. Does the following cause D to become undefined?  Ought it?

  integer :: I(2)
  double precision :: D
  equivalence ( D, I )
  d = 42.0
  i(1) = 666

2. Does the following cause C to become undefined?  Ought it?

  integer, parameter :: RK = kind(0.0d0)
  real(rk), pointer :: P
  complex(rk), target :: C = ( 1.0, 2.0 )
  c = ( 1.0d0, 2.0d0 )
  p => c%re
  p = 24.0d0

3. Does the following cause D1 to become undefined?  Does it cause C%IM
to become undefined?  Ought it?

  integer, parameter :: RK = kind(0.0d0)
  real(rk), pointer :: D1, D2
  complex(rk), target :: C
  c = ( 1.0d0, 2.0d0 )
  d1 => c%re
  d2 => c%im
  call s ( d2 )
  ...
  contains
    subroutine S ( D )
      real(rk), intent(out) :: D
  ....

4. Does the following cause Y to become undefined?  Ought it?

  type :: T1
    sequence
    integer :: C1 = 42
  end type T1
  type :: T2
    sequence
    real :: C1 = 42.0e0
  end type T2
  type(t1) :: X
  type(t2) :: Y
  equivalence ( X, Y )
  x = t1(21)

ANSWERS:

1. Item (1) in subclause 16.6.6 says

  "When a scalar variable of intrinsic type becomes defined, all totally
  associated variables of different type become undefined....  When a
  scalar variable becomes undefined, all partially associated double
  precision scalar variables become undefined."

D is not totally associated with I.  I does not become undefined.
Therefore, D does not become undefined.  D ought to become undefined.
Edits are provided to correct this mistake.

2. Item (1) in subclause 16.6.6 says

  "When a double precision scalar variable becomes defined, all
  partially associated scalar variables become undefined."

P is partly associated with C, and therefore C becomes undefined by the
assignment to the scalar variable P.  C ought not to become undefined.
Edits are provided to correct this mistake.

3. Item (1) in subclause 16.6.6 says

  "When a scalar variable becomes undefined, all partially associated
  double precision scalar variables become undefined."

  Subclause 16.6.1p5 says

  "A complex... scalar object is defined if and only if all of its
  subobjects are defined."

The association of the scalar variable D2 with an INTENT(OUT) dummy
argument causes it become undefined.  16.6.6p1(1) does not specify that
when a scalar real variable becomes undefined, a totally associated part
of a complex variable becomes undefined.  Assuming C%IM ought to become
undefined, then C ought to become undefined, even though C%RE is not
undefined.  D1 is associated with the C%RE, and therefore becomes
undefined when C%IM becomes undefined.  C%IM ought to become undefined,
and D1 ought not to become undefined.  Edits are provided to correct
this mistake.

4. Item (1) in subclause 16.6.6 says

  "When a scalar variable of intrinsic type becomes defined, all totally
  associated variables of different type become undefined.

X and Y are totally associated, and of different type, but neither one is
of intrinsic type.  Therefore, Y does not become undefined as a
consequence of X becoming defined.  Y ought to become undefined.  Edits
are provided to correct this mistake.

EDITS:

In Subclause 16.6.6p1, item(1), within the first sentence, remove "of
intrinsic type".  Before "different" insert "the same type with
different values of kind type parameters, or of"

In Subclause 16.6.6p1, replace item(1) with the following four sentences
(all in one paragraph)

  "When a scalar variable becomes defined, all totally associated
  variables of different type become undefined.

{Removing "of intrinsic type" from the existing first sentence of
16.6.6p1(1) addresses question 4.}

  When a scalar variable becomes defined, all partially associated
  variables of different type, or of the same type if corresponding kind
  type parameters have different values, become undefined, unless the
  scalar variable is totally associated with a subobject of the
  partially associated variable, that subobject is of the same type as
  the scalar variable, and corresponding kind type parameters have the
  same values.

{This addresses questions 1 and 2.  The references to kind type
parameter values address the possibility of partially associating a
double precision variable with a default real variable.  Default real
and double precision are now the same type (since 1990), but with a
different kind type parameter value.}

  When a scalar variable becomes undefined, all partially associated
  variables become undefined, unless the partially associated variable
  is totally associated with a subobject of the scalar variable that
  does not become undefined.

  When a scalar variable becomes undefined, all totally associated
  subobjects of other variables become undefined if those subobjects are
  of different type from the scalar variable, or corresponding kind type
  parameters have different values."

{The third and fourth sentences address question 3.}

SUBMITTED BY: Van Snyder

HISTORY: 14-195    m204  F08/0111 submitted - 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/20140908/33cdeae7/attachment-0001.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 14-233 interp LB #31 m205 due 6-Oct-2014.txt
Url: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140908/33cdeae7/attachment-0001.txt 



More information about the J3 mailing list