From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 12 05:19:32 2014 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 3C572357279; Fri, 12 Sep 2014 05:19:32 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by www.open-std.org (Postfix) with ESMTP id 16060357122 for ; Fri, 12 Sep 2014 05:19:23 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by fmsmga101.fm.intel.com with ESMTP; 11 Sep 2014 20:19:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,510,1406617200"; d="txt'?scan'208,217";a="477025711" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by azsmga001.ch.intel.com with ESMTP; 11 Sep 2014 20:19:18 -0700 Received: from orsmsx103.amr.corp.intel.com ([169.254.2.241]) by ORSMSX102.amr.corp.intel.com ([169.254.1.108]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 20:19:17 -0700 From: "Whitlock, Stan" To: WG5 Subject: J3 Fortran interp letter ballot #31 revised - due 6-Oct-2014 Thread-Topic: J3 Fortran interp letter ballot #31 revised - due 6-Oct-2014 Thread-Index: Ac/OOFSyTGKi5qHtSFCYFt7Kle8u5g== Date: Fri, 12 Sep 2014 03:19:17 +0000 Message-ID: <4AA982B1265F43408480F737BE12F4D35F93010C@ORSMSX103.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: multipart/mixed; boundary="_004_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_" MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_004_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_ Content-Type: multipart/alternative; boundary="_000_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_" --_000_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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=3D and ERRMSG=3D 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@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=3Dy%c) Q2. Is allocation of C permitted? class(*), pointer :: C type(lock_type), intent(in) :: L[*] allocate ( C, source=3DL ) 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 =3D> L Q5. Is this ALLOCATE statement conforming? CLASS(*),ALLOCATABLE :: C[:] TYPE(LOCK_TYPE) :: X ALLOCATE(C,MOLD=3DX) 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=3D appears, the declared type of 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=3D specifier and an", {There is no problem with MOLD=3D. "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=3D and ERRMSG=3D in ALLOCATE and DEALLOCATE KEYWORDS: STAT=3D, ERRMSG=3D, 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=3Dstat,ERRMSG=3Dtext(stat)) ! A DEALLOCATE(x,STAT=3Dstat,ERRMSG=3Dtext(stat)) ! B msg =3D '' ALLOCATE(y(999999,999999),STAT=3Distat(LEN_TRIM(msg)),ERRMSG=3Dmsg) ! C msg =3D '' DEALLOCATE(x,STAT=3Distat(LEN_TRIM(msg)),ERRMSG=3Dmsg) ! D In each of the statements labelled A-D, there is a dependency between the STAT=3D specifier and the ERRMSG=3D specifier (from STAT=3D to ERRMSG= =3D in A and B, and from ERRMSG=3D 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=3D specifier, p1, append "The shall not depend on the value of the .". [132:22] 6.7.5 ERRMSG=3D specifier, p1, append "The shall not depend on the value of the .". 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=3D, ERRMSG=3D, ACQUIRED_LOCK=3D, 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=3Dstat,ERRMSG=3Dtext(stat)) ! A SYNC IMAGES (*,STAT=3Dstat,ERRMSG=3Dtext(stat)) ! B SYNC MEMORY(STAT=3Dstat,ERRMSG=3Dtext(stat)) ! C LOCK(lock,ACQUIRED_LOCK=3Dacq, & STAT=3Distat(MERGE(1,2,acq)), & ERRMSG=3Dtext(istat(MERGE(1,2,acq)))) ! D UNLOCK(lock,STAT=3Dstat,ERRMSG=3Dtext(stat)) ! E LOCK(alock(stat),STAT=3Dstat) ! F msg =3D '' UNLOCK(alock(LEN_TRIM(msg)),STAT=3Dstat, & ERRMSG=3Dmsg) ! G stat =3D 13 SYNC IMAGES(stat,STAT=3Dstat) ! H msg =3D 'oops' SYNC IMAGES(LEN_TRIM(msg),STAT=3Dstat, & ERRMSG=3Dmsg) ! I In each of the statements labelled A-F, there is a dependency between the STAT=3D specifier and the ERRMSG=3D specifier. There appears to be no prohibition against this. Additionally, in the LOCK statement (D), there is a dependency between the ACQUIRED_LOCK=3D specifier and the STAT=3D specifier (there is no dependency between ACQUIRED_LOCK=3D and ERRMSG=3D 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=3D. In the LOCK statement (F), there is a dependency between the STAT=3D specifier and the lock variable. Similarly for the UNLOCK (G), there is a dependency between the lock variable and the ERRMSG=3D specifier. In the SYNC IMAGES statement (H), there is a dependency between the STAT=3D variable and the image set. In the SYNC IMAGES statement (I), there is a dependency between the ERRMSG=3D 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 shall not depend on the value of or .". [194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1, "The shall not depend on the value of , , or the in the ACQUIRED_LOCK=3D specifier. The shall not depend on the , , or .". [195:2-] 8.5.7 STAT=3D and ERRMSG=3D specifiers..., insert new p1, "The shall not depend on the value of the , , or the in the ACQUIRED_LOCK=3D specifier. The shall not depend on the value of the , , or the in the ACQUIRED_LOCK=3D 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 ---------------------------------------------------------------------- --_000_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         J3/14-233r1

To:        J3 Mem= bers

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:<= o:p>

 

    F08/0110   Interdepende= nce of specifier values in input/output

        &nbs= p;             =    statements

    F08/0111   Undefinition=

 

did not pass the J3 meeting so I am removing them fr= om 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 interp= retations.

 

The rules for interpretation handling by which we op= erate say:

 

    o   J3 votes on the ans= wer at a J3 meeting; a simple majority

        vote mark= s 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 mee= ting".  The letter ballot runs for 30 days.  Not<= /p>

        voting on= three of four consecutive J3 letter ballots is

        grounds t= o terminate J3 membership.  An interp answer passes

        by a 2/3r= ds vote;  a no vote must be accompanied by an

        explanati= on of the changes necessary to change the member's

        vote to y= es.

 

        J3/interp= reserves the right to recall an interp answer for

        more stud= y even if the answer passes.

 

5 Fortran interpretations are currently "Passed= by J3 meeting" after

J3 meeting #204.  This is the letter ballot pha= se to go from "Passed

by J3 meeting" to "Passed by J3 letter bal= lot".

 

The following Fortran interpretations are being ball= oted:

 

Yes  No   Number   &nb= sp; Title

 

---  ---  F08/0108   ultimate co= mponents and coarrays

---  ---  F08/0109   LOCK_TYPE a= nd unlimited polymorphic

---  ---  F08/0112   STAT=3D and= ERRMSG=3D in ALLOCATE and DEALLOCATE

---  ---  F08/0113   Specifiers = in image control statements

---  ---  F08/0114   Can LOCK_TY= PE 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 &quo= t;yes", -C- in the Yes

column for "yes with comment", or -N- in t= he No column for a "no"

answer {be sure to include your reasons with "n= o"} and send only the

above text {not this entire mail message} with any c= omments to

 

        j3@j3-for= tran.org

 

by 11:59:59PM, PDT, Monday, 6-Oct-2014, in order to = be counted.

 

 

Thanks       &nbs= p;            &= nbsp;    /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<= /o:p>

  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[:]<= o:p>

  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 su= ch 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 permitte= d.  X has an

   ultimate (allocatable) coarray componen= t (A[:]), and therefore

   acording to C526 must be a dummy argume= nt or have the ALLOCATABLE

   or SAVE attribute.

 

EDITS:

 

None.

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-163    m204  F08/010= 8 submitted

         14-= 163r1  m204  Fixed examples in questions, revised

        &nbs= p;            &= nbsp;   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<= o:p>

  END TYPE

  TYPE(t) :: x[*],y[*]

  ALLOCATE(y%c)

  ALLOCATE(x%c,SOURCE=3Dy%c)

 

Q2. Is allocation of C permitted?

 

  class(*), pointer :: C

  type(lock_type), intent(in) :: L[*]

 

  allocate ( C, source=3DL )

 

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 =3D> L

 

Q5. Is this ALLOCATE statement conforming?

 

  CLASS(*),ALLOCATABLE :: C[:]

  TYPE(LOCK_TYPE) :: X

  ALLOCATE(C,MOLD=3DX)

 

ANSWER:

 

A1. Allocation of X%C is not intended to be allowed.=   An edit is

    supplied to correct the requireme= nts on allocation of LOCK_TYPE.

 

A2. Allocation of C is not intended to be allowed.&n= bsp; An edit is

    supplied to correct the requireme= nts 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.&nbs= p; An edit is supplied

    to correct the requirements.=

 

EDITS:

 

[6:7+] After definition 1.3.33.2 parent componen= t, insert new term

  "1.3.33.2a

   potential subobject component

   nonpointer component, or potential subo= bject component of a

   nonpointer component (4.5.1)".

 

[127:8-9] 6.7.1.1 Syntax, C643,

        &nbs= p; Change "C_PTR," to "C_PTR or"

        &nbs= p; Delete ", LOCK_TYPE ... LOCK_TYPE".

 

[127:9+] Insert new constraint

  "C643a (R627) If SOURCE=3D appears, the = declared type of <source-expr>

         sha= ll not be LOCK_TYPE or have a potential subobject

         com= ponent of type LOCK_TYPE."

 

[127:18-19] 6.7.1.1, p4,

  "If" -> "If an ALLOCATE sta= tement has a SOURCE=3D specifier and an",

{There is no problem with MOLD=3D.  "subco= mponent" works ok here because

we have an object not a type.}

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-164    m204  F08/010= 9 submitted

         14-= 164r3  m204  As amended, passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0112

TITLE: STAT=3D and ERRMSG=3D in ALLOCATE and DEALLOC= ATE

KEYWORDS: STAT=3D, ERRMSG=3D, 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=3Dstat,ERRMSG=3Dtext(stat= )) ! A

  DEALLOCATE(x,STAT=3Dstat,ERRMSG=3Dtext(stat))=    ! B

  msg =3D ''

  ALLOCATE(y(999999,999999),STAT=3Distat(LEN_TR= IM(msg)),ERRMSG=3Dmsg) ! C

  msg =3D ''

  DEALLOCATE(x,STAT=3Distat(LEN_TRIM(msg)),ERRM= SG=3Dmsg) ! D

 

In each of the statements labelled A-D, there is a d= ependency between

the STAT=3D specifier and the ERRMSG=3D specifier (f= rom STAT=3D to ERRMSG=3D

in A and B, and from ERRMSG=3D to STAT in C and D).&= nbsp; There appears to be

no prohibition against this (though there are many p= rohibitions

against other dependencies in ALLOCATE and DEALLOCAT= E).

 

Are all these examples conforming, and if so, is the= dependent

variable referenced with the value of the other vari= able at the

beginning of execution of the statement or at the en= d of execution of

the statement?

 

ANSWER:

 

These are not standard-conforming, as no interpretat= ion is established

for them.  An edit is supplied to clarify this = prohibition.

 

EDITS:

 

[132:4] 6.7.4 STAT=3D specifier, p1, append

  "The <stat-variable> shall not dep= end on the value of the

   <errmsg-variable>.".

 

[132:22] 6.7.5 ERRMSG=3D specifier, p1, append<= /o:p>

  "The <errmsg-variable> shall not d= epend on the value of the

   <stat-variable>.".

 

SUBMITTED BY: Malcolm Cohen

 

HISTORY: 14-208    m204  F08/011= 2 submitted - passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0113

TITLE: Specifiers in image control statements

KEYWORDS: STAT=3D, ERRMSG=3D, ACQUIRED_LOCK=3D, imag= e 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=3Dstat,ERRMSG=3Dtext(stat))&nbs= p;      ! A

  SYNC IMAGES (*,STAT=3Dstat,ERRMSG=3Dtext(stat= )) ! B

  SYNC MEMORY(STAT=3Dstat,ERRMSG=3Dtext(stat))&= nbsp;   ! C

  LOCK(lock,ACQUIRED_LOCK=3Dacq, &

       STAT=3Distat(ME= RGE(1,2,acq)), &

       ERRMSG=3Dtext(i= stat(MERGE(1,2,acq))))    ! D

  UNLOCK(lock,STAT=3Dstat,ERRMSG=3Dtext(stat))&= nbsp;   ! E

  LOCK(alock(stat),STAT=3Dstat)  &nbs= p;            &= nbsp; ! F

  msg =3D ''

  UNLOCK(alock(LEN_TRIM(msg)),STAT=3Dstat, &= ;

         ERR= MSG=3Dmsg)           = ;            &n= bsp;  ! G

  stat =3D 13

  SYNC IMAGES(stat,STAT=3Dstat)  &nbs= p;            &= nbsp; ! H

  msg =3D 'oops'

  SYNC IMAGES(LEN_TRIM(msg),STAT=3Dstat, &<= o:p>

        &nbs= p;     ERRMSG=3Dmsg)      = ;            &n= bsp;  ! I

 

In each of the statements labelled A-F, there is a d= ependency between

the STAT=3D specifier and the ERRMSG=3D specifier.&n= bsp; There appears to be no

prohibition against this.

 

Additionally, in the LOCK statement (D), there is a = dependency between

the ACQUIRED_LOCK=3D specifier and the STAT=3D speci= fier (there is no

dependency between ACQUIRED_LOCK=3D and ERRMSG=3D be= cause the former is

only set on successful execution and the latter is o= nly set on an

error condition).  There appears to be no restr= ictions at all on any

dependencies from ACQUIRED_LOCK=3D.

 

In the LOCK statement (F), there is a dependency bet= ween the STAT=3D

specifier and the lock variable.  Similarly for= the UNLOCK (G), there

is a dependency between the lock variable and the ER= RMSG=3D specifier.

 

In the SYNC IMAGES statement (H), there is a depende= ncy between the

STAT=3D variable and the image set.  In the SYN= C IMAGES statement (I),

there is a dependency between the ERRMSG=3D variable= and the image set.

 

Are all these examples conforming, and if so, is the= dependent

variable referenced with the value of the other vari= able at the

beginning of execution of the statement or at the en= d of execution of

the statement?

 

ANSWER:

 

No interpretation is established and therefore these= are not

conforming.  An edit is provided to clarify thi= s.

 

EDITS:

 

[190:16-] 8.5.4 SYNC IMAGES statement, insert new p1= ,

  "The value of <image-set> shall no= t depend on the value of

   <stat-variable> or <errmsg-var= iable>.".

 

[194:6-] 8.5.6 LOCK and UNLOCK statements, insert ne= w p1,

  "The <lock-variable> shall not dep= end on the value of

   <stat-variable>, <errmsg-varia= ble>, or the

   <scalar-logical-variable> in the = ACQUIRED_LOCK=3D specifier.

   The <scalar-logical-variable> sha= ll not depend on the

   <lock-variable>, <stat-variabl= e>, or <errmsg-variable>.".

 

[195:2-] 8.5.7 STAT=3D and ERRMSG=3D specifiers..., = insert new p1,

  "The <stat-variable> shall not dep= end on the value of the

   <errmsg-variable>, <lock-varia= ble>, or the

   <scalar-logical-variable> in the = ACQUIRED_LOCK=3D specifier.

   The <errmsg-variable> shall not d= epend on the value of the

   <stat-variable>, <lock-variabl= e>, or the <scalar-logical-variable>

   in the ACQUIRED_LOCK=3D specifier."= ;.

 

SUBMITTED BY: Malcolm Cohen

 

HISTORY: 14-209    m204  F08/011= 3 submitted - passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0114

TITLE: Can LOCK_TYPE components have the POINTER att= ribute?

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 declarati= on 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 b= ecause 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 no= t 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, inse= rt new constraint

  "C1302a A component of type LOCK_TYPE, o= r that has a nonallocatable

         dir= ect component of type LOCK_TYPE, shall not have the

         POI= NTER attribute.".

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-140    m204  F08/011= 4 submitted

         14-= 140r1  m204  Revised to reverse decision

         14-= 140r2  m204  Passed by J3 meeting

 

----------------------------------------------------= ------------------

--_000_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_-- --_004_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_ Content-Type: text/plain; name="14-233r1 interp LB #31 revised m205 due 6-Oct-2014.txt" Content-Description: 14-233r1 interp LB #31 revised m205 due 6-Oct-2014.txt Content-Disposition: attachment; filename="14-233r1 interp LB #31 revised m205 due 6-Oct-2014.txt"; size=13030; creation-date="Fri, 12 Sep 2014 03:09:35 GMT"; modification-date="Thu, 11 Sep 2014 16:55:10 GMT" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK My8xNC0yMzNyMQ0KVG86ICAgICAgICBKMyBNZW1iZXJzDQpGcm9tOiAgICAgIFN0YW4gV2hpdGxv Y2sNClN1YmplY3Q6ICAgSjMgRm9ydHJhbiBpbnRlcnAgbGV0dGVyIGJhbGxvdCAjMzEgcmV2aXNl ZCAtIGR1ZSA2LU9jdC0yMDE0DQpEYXRlOiAgICAgIDExLVNlcC0yMDE0DQoNCkkgd2FzIG1pc3Rh a2VuIGFib3V0IHRoZSBpbnRlcnBzIHBhc3NlZCBhdCBtZWV0aW5nICMyMDQ6ICBvbmx5IDUNCmlu dGVycHMgd2VyZSBwYXNzZWQgbm90IDcuICBUaGVzZSB0d28gaW50ZXJwczoNCg0KICAgIEYwOC8w MTEwICAgSW50ZXJkZXBlbmRlbmNlIG9mIHNwZWNpZmllciB2YWx1ZXMgaW4gaW5wdXQvb3V0cHV0 DQogICAgICAgICAgICAgICAgc3RhdGVtZW50cw0KICAgIEYwOC8wMTExICAgVW5kZWZpbml0aW9u DQoNCmRpZCBub3QgcGFzcyB0aGUgSjMgbWVldGluZyBzbyBJIGFtIHJlbW92aW5nIHRoZW0gZnJv bSB0aGlzIGxldHRlcg0KYmFsbG90ICMzMS4gIFRoZSBiYWxsb3QgaXMgc3RpbGwgZHVlIDYtT2N0 LTIwMTQuICBNeSBhcG9sb2dpZXMgZm9yDQp0aGUgbWlzdW5kZXJzdGFuZGluZy4NCg0KRW5jbG9z ZWQgaW4gdGhlIG5leHQgbGV0dGVyIGJhbGxvdCBvbiBGb3J0cmFuIGludGVycHJldGF0aW9ucy4N Cg0KVGhlIHJ1bGVzIGZvciBpbnRlcnByZXRhdGlvbiBoYW5kbGluZyBieSB3aGljaCB3ZSBvcGVy YXRlIHNheToNCg0KICAgIG8gICBKMyB2b3RlcyBvbiB0aGUgYW5zd2VyIGF0IGEgSjMgbWVldGlu ZzsgYSBzaW1wbGUgbWFqb3JpdHkNCiAgICAgICAgdm90ZSBtYXJrcyB0aGUgYW5zd2VyIGFzICJw YXNzZWQgYnkgSjMgbWVldGluZyIuDQoNCiAgICBvICAgQmV0d2VlbiBKMyBtZWV0aW5ncyB0aGUg Y2hhaXIgb2YgL2ludGVycCBzZW5kcyBhIEozIGxldHRlcg0KICAgICAgICBiYWxsb3QgdG8gSjMg dG8gYXBwcm92ZSBpbnRlcnAgYW5zd2VycyB0aGF0IGhhdmUgYmVlbiAicGFzc2VkDQogICAgICAg IGJ5IEozIG1lZXRpbmciLiAgVGhlIGxldHRlciBiYWxsb3QgcnVucyBmb3IgMzAgZGF5cy4gIE5v dA0KICAgICAgICB2b3Rpbmcgb24gdGhyZWUgb2YgZm91ciBjb25zZWN1dGl2ZSBKMyBsZXR0ZXIg YmFsbG90cyBpcw0KICAgICAgICBncm91bmRzIHRvIHRlcm1pbmF0ZSBKMyBtZW1iZXJzaGlwLiAg QW4gaW50ZXJwIGFuc3dlciBwYXNzZXMNCiAgICAgICAgYnkgYSAyLzNyZHMgdm90ZTsgIGEgbm8g dm90ZSBtdXN0IGJlIGFjY29tcGFuaWVkIGJ5IGFuDQogICAgICAgIGV4cGxhbmF0aW9uIG9mIHRo ZSBjaGFuZ2VzIG5lY2Vzc2FyeSB0byBjaGFuZ2UgdGhlIG1lbWJlcidzDQogICAgICAgIHZvdGUg dG8geWVzLg0KDQogICAgICAgIEozL2ludGVycCByZXNlcnZlcyB0aGUgcmlnaHQgdG8gcmVjYWxs IGFuIGludGVycCBhbnN3ZXIgZm9yDQogICAgICAgIG1vcmUgc3R1ZHkgZXZlbiBpZiB0aGUgYW5z d2VyIHBhc3Nlcy4NCg0KNSBGb3J0cmFuIGludGVycHJldGF0aW9ucyBhcmUgY3VycmVudGx5ICJQ YXNzZWQgYnkgSjMgbWVldGluZyIgYWZ0ZXINCkozIG1lZXRpbmcgIzIwNC4gIFRoaXMgaXMgdGhl IGxldHRlciBiYWxsb3QgcGhhc2UgdG8gZ28gZnJvbSAiUGFzc2VkDQpieSBKMyBtZWV0aW5nIiB0 byAiUGFzc2VkIGJ5IEozIGxldHRlciBiYWxsb3QiLg0KDQpUaGUgZm9sbG93aW5nIEZvcnRyYW4g aW50ZXJwcmV0YXRpb25zIGFyZSBiZWluZyBiYWxsb3RlZDoNCg0KWWVzICBObyAgIE51bWJlciAg ICAgVGl0bGUNCg0KLS0tICAtLS0gIEYwOC8wMTA4ICAgdWx0aW1hdGUgY29tcG9uZW50cyBhbmQg Y29hcnJheXMNCi0tLSAgLS0tICBGMDgvMDEwOSAgIExPQ0tfVFlQRSBhbmQgdW5saW1pdGVkIHBv bHltb3JwaGljDQotLS0gIC0tLSAgRjA4LzAxMTIgICBTVEFUPSBhbmQgRVJSTVNHPSBpbiBBTExP Q0FURSBhbmQgREVBTExPQ0FURQ0KLS0tICAtLS0gIEYwOC8wMTEzICAgU3BlY2lmaWVycyBpbiBp bWFnZSBjb250cm9sIHN0YXRlbWVudHMNCi0tLSAgLS0tICBGMDgvMDExNCAgIENhbiBMT0NLX1RZ UEUgY29tcG9uZW50cyBoYXZlIHRoZSBQT0lOVEVSIGF0dHJpYnV0ZT8NCg0KVGhlIHRleHQgb2Yg dGhlc2UgaW50ZXJwcmV0YXRpb25zIGlzIGF0dGFjaGVkLiAgRWFjaCBpbnRlcnByZXRhdGlvbg0K c3RhcnRzIHdpdGggYSByb3cgb2YgIi0icy4NCg0KUGxlYXNlIG1hcmsgdGhlIGFib3ZlIC1ZLSBp biB0aGUgWWVzIGNvbHVtbiBmb3IgInllcyIsIC1DLSBpbiB0aGUgWWVzDQpjb2x1bW4gZm9yICJ5 ZXMgd2l0aCBjb21tZW50Iiwgb3IgLU4tIGluIHRoZSBObyBjb2x1bW4gZm9yIGEgIm5vIg0KYW5z d2VyIHtiZSBzdXJlIHRvIGluY2x1ZGUgeW91ciByZWFzb25zIHdpdGggIm5vIn0gYW5kIHNlbmQg b25seSB0aGUNCmFib3ZlIHRleHQge25vdCB0aGlzIGVudGlyZSBtYWlsIG1lc3NhZ2V9IHdpdGgg YW55IGNvbW1lbnRzIHRvDQoNCiAgICAgICAgajNAajMtZm9ydHJhbi5vcmcNCg0KYnkgMTE6NTk6 NTlQTSwgUERULCBNb25kYXksIDYtT2N0LTIwMTQsIGluIG9yZGVyIHRvIGJlIGNvdW50ZWQuDQoN Cg0KVGhhbmtzICAgICAgICAgICAgICAgICAgICAgICAgIC9TdGFuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpOVU1CRVI6IEYwOC8wMTA4DQpUSVRMRTogdWx0aW1hdGUgY29tcG9uZW50cyBhbmQgY29h cnJheXMNCktFWVdPUkQ6IHVsdGltYXRlIGNvbXBvbmVudHMsIGNvYXJyYXlzDQpERUZFQ1QgVFlQ RTogSW50ZXJwcmV0YXRpb24NClNUQVRVUzogUGFzc2VkIGJ5IEozIG1lZXRpbmcNCg0KUVVFU1RJ T05TOg0KDQoxLiBJcyB0aGUgZGVjbGFyYXRpb24gb2YgViBwZXJtaXR0ZWQ6DQoNCiAgdHlwZSA6 OiBvbmUNCiAgICByZWFsLCBhbGxvY2F0YWJsZSA6OiBDWzpdDQogIGVuZCB0eXBlIG9uZQ0KDQog IHR5cGUgOjogdHdvDQogICAgdHlwZShvbmUpLCBhbGxvY2F0YWJsZSA6OiBBDQogIGVuZCB0eXBl IHR3bw0KDQogIHR5cGUodHdvKSwgcG9pbnRlciA6OiBWKDopDQoNCjIuIElzIHRoZSBkZWNsYXJh dGlvbiBvZiBYIHBlcm1pdHRlZDoNCg0KICB0eXBlIDo6IHRocmVlDQogICAgcmVhbCA6OiBDDQog IGVuZCB0eXBlIHRocmVlDQoNCiAgdHlwZSA6OiBmb3VyDQogICAgdHlwZSh0aHJlZSksIGFsbG9j YXRhYmxlIDo6IEFbOl0NCiAgZW5kIHR5cGUgZm91cg0KDQogIHR5cGUoZm91cikgOjogWA0KDQpB TlNXRVJTOg0KDQoxLiBUeXBlIHR3byBpcyBub3QgY29uZm9ybWluZywgYmVjYXVzZSB0aGUgZW50 aXR5IEEgaGFzIGEgY29hcnJheQ0KICAgdWx0aW1hdGUgY29tcG9uZW50IGFuZCBDNTI1IHJlcXVp cmVzIHN1Y2ggYW4gZW50aXR5IHRvIGJlIGENCiAgIG5vbnBvaW50ZXIgbm9uYWxsb2NhdGFibGUg c2NhbGFyLiAgVGhlcmVmb3JlIHRoZSBkZWNsYXJhdGlvbiBvZiBWDQogICBpcyBub3QgcGVybWl0 dGVkLg0KDQoyLiBYIHNhdGlzZmllcyBDNTI1LCBzbyBkZWNsYXJhdGlvbiBvZiBYIGlzIHBlcm1p dHRlZC4gIFggaGFzIGFuDQogICB1bHRpbWF0ZSAoYWxsb2NhdGFibGUpIGNvYXJyYXkgY29tcG9u ZW50IChBWzpdKSwgYW5kIHRoZXJlZm9yZQ0KICAgYWNvcmRpbmcgdG8gQzUyNiBtdXN0IGJlIGEg ZHVtbXkgYXJndW1lbnQgb3IgaGF2ZSB0aGUgQUxMT0NBVEFCTEUNCiAgIG9yIFNBVkUgYXR0cmli dXRlLg0KDQpFRElUUzoNCg0KTm9uZS4NCg0KU1VCTUlUVEVEIEJZOiBWYW4gU255ZGVyDQoNCkhJ U1RPUlk6IDE0LTE2MyAgICBtMjA0ICBGMDgvMDEwOCBzdWJtaXR0ZWQNCiAgICAgICAgIDE0LTE2 M3IxICBtMjA0ICBGaXhlZCBleGFtcGxlcyBpbiBxdWVzdGlvbnMsIHJldmlzZWQNCiAgICAgICAg ICAgICAgICAgICAgICAgICBhbnN3ZXIgLSBwYXNzZWQgYnkgSjMgbWVldGluZw0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCk5VTUJFUjogRjA4LzAxMDkNClRJVExFOiBMT0NLX1RZUEUgYW5kIHVubGltaXRl ZCBwb2x5bW9ycGhpYw0KS0VZV09SRDogTE9DS19UWVBFLCB1bmxpbWl0ZWQgcG9seW1vcnBoaWMN CkRFRkVDVCBUWVBFOiBFcnJhdHVtDQpTVEFUVVM6IFBhc3NlZCBieSBKMyBtZWV0aW5nDQoNClFV RVNUSU9OOg0KDQpBc3N1bWUgdHlwZSBMT0NLX1RZUEUgZnJvbSB0aGUgaW50cmluc2ljIG1vZHVs ZSBJU09fRm9ydHJhbl9FbnYgaXMNCmF2YWlsYWJsZS4NCg0KUTEuIElzIGFsbG9jYXRpb24gb2Yg WCVDIHBlcm1pdHRlZD8NCg0KICBUWVBFIHQNCiAgICBUWVBFKExPQ0tfVFlQRSksQUxMT0NBVEFC TEUgOjogYw0KICBFTkQgVFlQRQ0KICBUWVBFKHQpIDo6IHhbKl0seVsqXQ0KICBBTExPQ0FURSh5 JWMpDQogIEFMTE9DQVRFKHglYyxTT1VSQ0U9eSVjKQ0KDQpRMi4gSXMgYWxsb2NhdGlvbiBvZiBD IHBlcm1pdHRlZD8NCg0KICBjbGFzcygqKSwgcG9pbnRlciA6OiBDDQogIHR5cGUobG9ja190eXBl KSwgaW50ZW50KGluKSA6OiBMWypdDQoNCiAgYWxsb2NhdGUgKCBDLCBzb3VyY2U9TCApDQoNClEz LiBJcyBhbGxvY2F0aW9uIG9mIEMgcGVybWl0dGVkPw0KDQogIGNsYXNzKCopLCBwb2ludGVyIDo6 IEMNCg0KICBhbGxvY2F0ZSAoIExPQ0tfVFlQRSA6OiBDICkNCg0KUTQuIElzIHBvaW50ZXIgYXNz aWdubWVudCB0byBDIHBlcm1pdHRlZD8NCg0KICBjbGFzcygqKSwgcG9pbnRlciA6OiBDDQogIHR5 cGUobG9ja190eXBlKSwgaW50ZW50KGluKSwgdGFyZ2V0IDo6IExbKl0NCg0KICBjID0+IEwNCg0K UTUuIElzIHRoaXMgQUxMT0NBVEUgc3RhdGVtZW50IGNvbmZvcm1pbmc/DQoNCiAgQ0xBU1MoKiks QUxMT0NBVEFCTEUgOjogQ1s6XQ0KICBUWVBFKExPQ0tfVFlQRSkgOjogWA0KICBBTExPQ0FURShD LE1PTEQ9WCkNCg0KQU5TV0VSOg0KDQpBMS4gQWxsb2NhdGlvbiBvZiBYJUMgaXMgbm90IGludGVu ZGVkIHRvIGJlIGFsbG93ZWQuICBBbiBlZGl0IGlzDQogICAgc3VwcGxpZWQgdG8gY29ycmVjdCB0 aGUgcmVxdWlyZW1lbnRzIG9uIGFsbG9jYXRpb24gb2YgTE9DS19UWVBFLg0KDQpBMi4gQWxsb2Nh dGlvbiBvZiBDIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBhbGxvd2VkLiAgQW4gZWRpdCBpcw0KICAg IHN1cHBsaWVkIHRvIGNvcnJlY3QgdGhlIHJlcXVpcmVtZW50cyBvbiBhbGxvY2F0aW9uIG9mIExP Q0tfVFlQRS4NCg0KQTMuIFRoaXMgYWxsb2NhdGlvbiBvZiBDIGlzIHBlcm1pdHRlZC4NCg0KQTQu IFBvaW50ZXIgYXNzaWdubWVudCB0byBDIGlzIHBlcm1pdHRlZC4NCg0KQTUuIFRoaXMgc3RhdGVt ZW50IHdhcyBpbnRlbmRlZCB0byBiZSBwZXJtaXR0ZWQuICBBbiBlZGl0IGlzIHN1cHBsaWVkDQog ICAgdG8gY29ycmVjdCB0aGUgcmVxdWlyZW1lbnRzLg0KDQpFRElUUzoNCg0KWzY6NytdIEFmdGVy IGRlZmluaXRpb24gMS4zLjMzLjIgcGFyZW50IGNvbXBvbmVudCwgaW5zZXJ0IG5ldyB0ZXJtDQog ICIxLjMuMzMuMmENCiAgIHBvdGVudGlhbCBzdWJvYmplY3QgY29tcG9uZW50DQogICBub25wb2lu dGVyIGNvbXBvbmVudCwgb3IgcG90ZW50aWFsIHN1Ym9iamVjdCBjb21wb25lbnQgb2YgYQ0KICAg bm9ucG9pbnRlciBjb21wb25lbnQgKDQuNS4xKSIuDQoNClsxMjc6OC05XSA2LjcuMS4xIFN5bnRh eCwgQzY0MywNCiAgICAgICAgICBDaGFuZ2UgIkNfUFRSLCIgdG8gIkNfUFRSIG9yIg0KICAgICAg ICAgIERlbGV0ZSAiLCBMT0NLX1RZUEUgLi4uIExPQ0tfVFlQRSIuDQoNClsxMjc6OStdIEluc2Vy dCBuZXcgY29uc3RyYWludA0KICAiQzY0M2EgKFI2MjcpIElmIFNPVVJDRT0gYXBwZWFycywgdGhl IGRlY2xhcmVkIHR5cGUgb2YgPHNvdXJjZS1leHByPg0KICAgICAgICAgc2hhbGwgbm90IGJlIExP Q0tfVFlQRSBvciBoYXZlIGEgcG90ZW50aWFsIHN1Ym9iamVjdA0KICAgICAgICAgY29tcG9uZW50 IG9mIHR5cGUgTE9DS19UWVBFLiINCg0KWzEyNzoxOC0xOV0gNi43LjEuMSwgcDQsDQogICJJZiIg LT4gIklmIGFuIEFMTE9DQVRFIHN0YXRlbWVudCBoYXMgYSBTT1VSQ0U9IHNwZWNpZmllciBhbmQg YW4iLA0Ke1RoZXJlIGlzIG5vIHByb2JsZW0gd2l0aCBNT0xEPS4gICJzdWJjb21wb25lbnQiIHdv cmtzIG9rIGhlcmUgYmVjYXVzZQ0KIHdlIGhhdmUgYW4gb2JqZWN0IG5vdCBhIHR5cGUufQ0KDQpT VUJNSVRURUQgQlk6IFZhbiBTbnlkZXINCg0KSElTVE9SWTogMTQtMTY0ICAgIG0yMDQgIEYwOC8w MTA5IHN1Ym1pdHRlZA0KICAgICAgICAgMTQtMTY0cjMgIG0yMDQgIEFzIGFtZW5kZWQsIHBhc3Nl ZCBieSBKMyBtZWV0aW5nDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTlVNQkVSOiBGMDgvMDExMg0KVElU TEU6IFNUQVQ9IGFuZCBFUlJNU0c9IGluIEFMTE9DQVRFIGFuZCBERUFMTE9DQVRFDQpLRVlXT1JE UzogU1RBVD0sIEVSUk1TRz0sIEFMTE9DQVRFLCBERUFMTE9DQVRFDQpERUZFQ1QgVFlQRTogRXJy YXR1bQ0KU1RBVFVTOiBQYXNzZWQgYnkgSjMgbWVldGluZw0KDQpRVUVTVElPTjoNCg0KQ29uc2lk ZXINCg0KICBDSEFSQUNURVIoODApIHRleHQoMDoxMDApLCBtc2cNCiAgSU5URUdFUiBzdGF0LGlz dGF0KDA6ODApDQogIFJFQUwsQUxMT0NBVEFCTEUgOjogeCg6KSx5KDosOikNCiAgLi4uDQogIEFM TE9DQVRFKHgoMTApLFNUQVQ9c3RhdCxFUlJNU0c9dGV4dChzdGF0KSkgISBBDQogIERFQUxMT0NB VEUoeCxTVEFUPXN0YXQsRVJSTVNHPXRleHQoc3RhdCkpICAgISBCDQogIG1zZyA9ICcnDQogIEFM TE9DQVRFKHkoOTk5OTk5LDk5OTk5OSksU1RBVD1pc3RhdChMRU5fVFJJTShtc2cpKSxFUlJNU0c9 bXNnKSAhIEMNCiAgbXNnID0gJycNCiAgREVBTExPQ0FURSh4LFNUQVQ9aXN0YXQoTEVOX1RSSU0o bXNnKSksRVJSTVNHPW1zZykgISBEDQoNCkluIGVhY2ggb2YgdGhlIHN0YXRlbWVudHMgbGFiZWxs ZWQgQS1ELCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kgYmV0d2Vlbg0KdGhlIFNUQVQ9IHNwZWNpZmll ciBhbmQgdGhlIEVSUk1TRz0gc3BlY2lmaWVyIChmcm9tIFNUQVQ9IHRvIEVSUk1TRz0NCmluIEEg YW5kIEIsIGFuZCBmcm9tIEVSUk1TRz0gdG8gU1RBVCBpbiBDIGFuZCBEKS4gIFRoZXJlIGFwcGVh cnMgdG8gYmUNCm5vIHByb2hpYml0aW9uIGFnYWluc3QgdGhpcyAodGhvdWdoIHRoZXJlIGFyZSBt YW55IHByb2hpYml0aW9ucw0KYWdhaW5zdCBvdGhlciBkZXBlbmRlbmNpZXMgaW4gQUxMT0NBVEUg YW5kIERFQUxMT0NBVEUpLg0KDQpBcmUgYWxsIHRoZXNlIGV4YW1wbGVzIGNvbmZvcm1pbmcsIGFu ZCBpZiBzbywgaXMgdGhlIGRlcGVuZGVudA0KdmFyaWFibGUgcmVmZXJlbmNlZCB3aXRoIHRoZSB2 YWx1ZSBvZiB0aGUgb3RoZXIgdmFyaWFibGUgYXQgdGhlDQpiZWdpbm5pbmcgb2YgZXhlY3V0aW9u IG9mIHRoZSBzdGF0ZW1lbnQgb3IgYXQgdGhlIGVuZCBvZiBleGVjdXRpb24gb2YNCnRoZSBzdGF0 ZW1lbnQ/DQoNCkFOU1dFUjoNCg0KVGhlc2UgYXJlIG5vdCBzdGFuZGFyZC1jb25mb3JtaW5nLCBh cyBubyBpbnRlcnByZXRhdGlvbiBpcyBlc3RhYmxpc2hlZA0KZm9yIHRoZW0uICBBbiBlZGl0IGlz IHN1cHBsaWVkIHRvIGNsYXJpZnkgdGhpcyBwcm9oaWJpdGlvbi4NCg0KRURJVFM6DQoNClsxMzI6 NF0gNi43LjQgU1RBVD0gc3BlY2lmaWVyLCBwMSwgYXBwZW5kDQogICJUaGUgPHN0YXQtdmFyaWFi bGU+IHNoYWxsIG5vdCBkZXBlbmQgb24gdGhlIHZhbHVlIG9mIHRoZQ0KICAgPGVycm1zZy12YXJp YWJsZT4uIi4NCg0KWzEzMjoyMl0gNi43LjUgRVJSTVNHPSBzcGVjaWZpZXIsIHAxLCBhcHBlbmQN CiAgIlRoZSA8ZXJybXNnLXZhcmlhYmxlPiBzaGFsbCBub3QgZGVwZW5kIG9uIHRoZSB2YWx1ZSBv ZiB0aGUNCiAgIDxzdGF0LXZhcmlhYmxlPi4iLg0KDQpTVUJNSVRURUQgQlk6IE1hbGNvbG0gQ29o ZW4NCg0KSElTVE9SWTogMTQtMjA4ICAgIG0yMDQgIEYwOC8wMTEyIHN1Ym1pdHRlZCAtIHBhc3Nl ZCBieSBKMyBtZWV0aW5nDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTlVNQkVSOiBGMDgvMDExMw0KVElU TEU6IFNwZWNpZmllcnMgaW4gaW1hZ2UgY29udHJvbCBzdGF0ZW1lbnRzDQpLRVlXT1JEUzogU1RB VD0sIEVSUk1TRz0sIEFDUVVJUkVEX0xPQ0s9LCBpbWFnZSBjb250cm9sDQpERUZFQ1QgVFlQRTog RXJyYXR1bQ0KU1RBVFVTOiBQYXNzZWQgYnkgSjMgbWVldGluZw0KDQpRVUVTVElPTjoNCg0KQ29u c2lkZXINCg0KICBDSEFSQUNURVIoODApIHRleHQoMDoxMDApLG1zZw0KICBJTlRFR0VSIHN0YXQs aXN0YXQoMikNCiAgUkVBTCxBTExPQ0FUQUJMRSA6OiB4KDopDQogIFRZUEUoTE9DS19UWVBFKSA6 OiBsb2NrWypdLCBhbG9jaygwOjgwKVsqXQ0KICBMT0dJQ0FMIGFjcSwgYWFjcSgwOjgwKQ0KICAu Li4NCiAgU1lOQyBBTEwoU1RBVD1zdGF0LEVSUk1TRz10ZXh0KHN0YXQpKSAgICAgICAhIEENCiAg U1lOQyBJTUFHRVMgKCosU1RBVD1zdGF0LEVSUk1TRz10ZXh0KHN0YXQpKSAhIEINCiAgU1lOQyBN RU1PUlkoU1RBVD1zdGF0LEVSUk1TRz10ZXh0KHN0YXQpKSAgICAhIEMNCiAgTE9DSyhsb2NrLEFD UVVJUkVEX0xPQ0s9YWNxLCAmDQogICAgICAgU1RBVD1pc3RhdChNRVJHRSgxLDIsYWNxKSksICYN CiAgICAgICBFUlJNU0c9dGV4dChpc3RhdChNRVJHRSgxLDIsYWNxKSkpKSAgICAhIEQNCiAgVU5M T0NLKGxvY2ssU1RBVD1zdGF0LEVSUk1TRz10ZXh0KHN0YXQpKSAgICAhIEUNCiAgTE9DSyhhbG9j ayhzdGF0KSxTVEFUPXN0YXQpICAgICAgICAgICAgICAgICAhIEYNCiAgbXNnID0gJycNCiAgVU5M T0NLKGFsb2NrKExFTl9UUklNKG1zZykpLFNUQVQ9c3RhdCwgJg0KICAgICAgICAgRVJSTVNHPW1z ZykgICAgICAgICAgICAgICAgICAgICAgICAgICEgRw0KICBzdGF0ID0gMTMNCiAgU1lOQyBJTUFH RVMoc3RhdCxTVEFUPXN0YXQpICAgICAgICAgICAgICAgICAhIEgNCiAgbXNnID0gJ29vcHMnDQog IFNZTkMgSU1BR0VTKExFTl9UUklNKG1zZyksU1RBVD1zdGF0LCAmDQogICAgICAgICAgICAgIEVS Uk1TRz1tc2cpICAgICAgICAgICAgICAgICAgICAgISBJDQoNCkluIGVhY2ggb2YgdGhlIHN0YXRl bWVudHMgbGFiZWxsZWQgQS1GLCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kgYmV0d2Vlbg0KdGhlIFNU QVQ9IHNwZWNpZmllciBhbmQgdGhlIEVSUk1TRz0gc3BlY2lmaWVyLiAgVGhlcmUgYXBwZWFycyB0 byBiZSBubw0KcHJvaGliaXRpb24gYWdhaW5zdCB0aGlzLg0KDQpBZGRpdGlvbmFsbHksIGluIHRo ZSBMT0NLIHN0YXRlbWVudCAoRCksIHRoZXJlIGlzIGEgZGVwZW5kZW5jeSBiZXR3ZWVuDQp0aGUg QUNRVUlSRURfTE9DSz0gc3BlY2lmaWVyIGFuZCB0aGUgU1RBVD0gc3BlY2lmaWVyICh0aGVyZSBp cyBubw0KZGVwZW5kZW5jeSBiZXR3ZWVuIEFDUVVJUkVEX0xPQ0s9IGFuZCBFUlJNU0c9IGJlY2F1 c2UgdGhlIGZvcm1lciBpcw0Kb25seSBzZXQgb24gc3VjY2Vzc2Z1bCBleGVjdXRpb24gYW5kIHRo ZSBsYXR0ZXIgaXMgb25seSBzZXQgb24gYW4NCmVycm9yIGNvbmRpdGlvbikuICBUaGVyZSBhcHBl YXJzIHRvIGJlIG5vIHJlc3RyaWN0aW9ucyBhdCBhbGwgb24gYW55DQpkZXBlbmRlbmNpZXMgZnJv bSBBQ1FVSVJFRF9MT0NLPS4NCg0KSW4gdGhlIExPQ0sgc3RhdGVtZW50IChGKSwgdGhlcmUgaXMg YSBkZXBlbmRlbmN5IGJldHdlZW4gdGhlIFNUQVQ9DQpzcGVjaWZpZXIgYW5kIHRoZSBsb2NrIHZh cmlhYmxlLiAgU2ltaWxhcmx5IGZvciB0aGUgVU5MT0NLIChHKSwgdGhlcmUNCmlzIGEgZGVwZW5k ZW5jeSBiZXR3ZWVuIHRoZSBsb2NrIHZhcmlhYmxlIGFuZCB0aGUgRVJSTVNHPSBzcGVjaWZpZXIu DQoNCkluIHRoZSBTWU5DIElNQUdFUyBzdGF0ZW1lbnQgKEgpLCB0aGVyZSBpcyBhIGRlcGVuZGVu Y3kgYmV0d2VlbiB0aGUNClNUQVQ9IHZhcmlhYmxlIGFuZCB0aGUgaW1hZ2Ugc2V0LiAgSW4gdGhl IFNZTkMgSU1BR0VTIHN0YXRlbWVudCAoSSksDQp0aGVyZSBpcyBhIGRlcGVuZGVuY3kgYmV0d2Vl biB0aGUgRVJSTVNHPSB2YXJpYWJsZSBhbmQgdGhlIGltYWdlIHNldC4NCg0KQXJlIGFsbCB0aGVz ZSBleGFtcGxlcyBjb25mb3JtaW5nLCBhbmQgaWYgc28sIGlzIHRoZSBkZXBlbmRlbnQNCnZhcmlh YmxlIHJlZmVyZW5jZWQgd2l0aCB0aGUgdmFsdWUgb2YgdGhlIG90aGVyIHZhcmlhYmxlIGF0IHRo ZQ0KYmVnaW5uaW5nIG9mIGV4ZWN1dGlvbiBvZiB0aGUgc3RhdGVtZW50IG9yIGF0IHRoZSBlbmQg b2YgZXhlY3V0aW9uIG9mDQp0aGUgc3RhdGVtZW50Pw0KDQpBTlNXRVI6DQoNCk5vIGludGVycHJl dGF0aW9uIGlzIGVzdGFibGlzaGVkIGFuZCB0aGVyZWZvcmUgdGhlc2UgYXJlIG5vdA0KY29uZm9y bWluZy4gIEFuIGVkaXQgaXMgcHJvdmlkZWQgdG8gY2xhcmlmeSB0aGlzLg0KDQpFRElUUzoNCg0K WzE5MDoxNi1dIDguNS40IFNZTkMgSU1BR0VTIHN0YXRlbWVudCwgaW5zZXJ0IG5ldyBwMSwNCiAg IlRoZSB2YWx1ZSBvZiA8aW1hZ2Utc2V0PiBzaGFsbCBub3QgZGVwZW5kIG9uIHRoZSB2YWx1ZSBv Zg0KICAgPHN0YXQtdmFyaWFibGU+IG9yIDxlcnJtc2ctdmFyaWFibGU+LiIuDQoNClsxOTQ6Ni1d IDguNS42IExPQ0sgYW5kIFVOTE9DSyBzdGF0ZW1lbnRzLCBpbnNlcnQgbmV3IHAxLA0KICAiVGhl IDxsb2NrLXZhcmlhYmxlPiBzaGFsbCBub3QgZGVwZW5kIG9uIHRoZSB2YWx1ZSBvZg0KICAgPHN0 YXQtdmFyaWFibGU+LCA8ZXJybXNnLXZhcmlhYmxlPiwgb3IgdGhlDQogICA8c2NhbGFyLWxvZ2lj YWwtdmFyaWFibGU+IGluIHRoZSBBQ1FVSVJFRF9MT0NLPSBzcGVjaWZpZXIuDQogICBUaGUgPHNj YWxhci1sb2dpY2FsLXZhcmlhYmxlPiBzaGFsbCBub3QgZGVwZW5kIG9uIHRoZQ0KICAgPGxvY2st dmFyaWFibGU+LCA8c3RhdC12YXJpYWJsZT4sIG9yIDxlcnJtc2ctdmFyaWFibGU+LiIuDQoNClsx OTU6Mi1dIDguNS43IFNUQVQ9IGFuZCBFUlJNU0c9IHNwZWNpZmllcnMuLi4sIGluc2VydCBuZXcg cDEsDQogICJUaGUgPHN0YXQtdmFyaWFibGU+IHNoYWxsIG5vdCBkZXBlbmQgb24gdGhlIHZhbHVl IG9mIHRoZQ0KICAgPGVycm1zZy12YXJpYWJsZT4sIDxsb2NrLXZhcmlhYmxlPiwgb3IgdGhlDQog ICA8c2NhbGFyLWxvZ2ljYWwtdmFyaWFibGU+IGluIHRoZSBBQ1FVSVJFRF9MT0NLPSBzcGVjaWZp ZXIuDQogICBUaGUgPGVycm1zZy12YXJpYWJsZT4gc2hhbGwgbm90IGRlcGVuZCBvbiB0aGUgdmFs dWUgb2YgdGhlDQogICA8c3RhdC12YXJpYWJsZT4sIDxsb2NrLXZhcmlhYmxlPiwgb3IgdGhlIDxz Y2FsYXItbG9naWNhbC12YXJpYWJsZT4NCiAgIGluIHRoZSBBQ1FVSVJFRF9MT0NLPSBzcGVjaWZp ZXIuIi4NCg0KU1VCTUlUVEVEIEJZOiBNYWxjb2xtIENvaGVuDQoNCkhJU1RPUlk6IDE0LTIwOSAg ICBtMjA0ICBGMDgvMDExMyBzdWJtaXR0ZWQgLSBwYXNzZWQgYnkgSjMgbWVldGluZw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCk5VTUJFUjogRjA4LzAxMTQNClRJVExFOiBDYW4gTE9DS19UWVBFIGNvbXBv bmVudHMgaGF2ZSB0aGUgUE9JTlRFUiBhdHRyaWJ1dGU/DQpLRVlXT1JEOiBMT0NLX1RZUEUgY29t cG9uZW50LCBQT0lOVEVSDQpERUZFQ1QgVFlQRTogRXJyYXR1bQ0KU1RBVFVTOiBQYXNzZWQgYnkg SjMgbWVldGluZw0KDQpBc3N1bWUgTE9DS19UWVBFIGlzIGFjY2Vzc2libGUgZnJvbSBJU09fRm9y dHJhbl9FbnYuDQoNClFVRVNUSU9OOg0KDQpUaGUgZm9sbG93aW5nIHR5cGUgZGVmaW5pdGlvbiBh bmQgdmFyaWFibGUgZGVjbGFyYXRpb24gYXJlIHBlcm1pdHRlZCBieQ0KQzEzMDI6DQoNCiAgdHlw ZSA6OiBPbmUNCiAgICB0eXBlKGxvY2tfdHlwZSksIHBvaW50ZXIgOjogTA0KICBlbmQgdHlwZSBP bmUNCg0KICB0eXBlKG9uZSksIGFsbG9jYXRhYmxlIDo6IEwxWypdDQoNCkMxMzAyIHJlcXVpcmVz IGEgbmFtZWQgdmFyaWFibGUgb2YgTE9DS19UWVBFIHRvIGJlIGEgY29hcnJheS4gIEM1MjYNCnJl cXVpcmVzIGEgY29hcnJheSB0byBiZSBhbGxvY2F0YWJsZSBvciB0byBoYXZlIHRoZSBTQVZFIGF0 dHJpYnV0ZS4NCg0KVGhlIGZvbGxvd2luZyBkZWNsYXJhdGlvbiBpcyBhcHBhcmVudGx5IHByb2hp Yml0ZWQgYmVjYXVzZSBMNCBpcw0Kbm90IGEgY29hcnJheToNCg0KICB0eXBlKGxvY2tfdHlwZSks IHBvaW50ZXIgOjogTDQNCg0KV2FzIGl0IGludGVuZGVkIHRoYXQgcG9pbnRlciBjb21wb25lbnRz IG9mIHR5cGUgTE9DS19UWVBFIGJlIHBlcm1pdHRlZCwNCmJ1dCB0aGF0IG5hbWVkIHZhcmlhYmxl cyBvZiB0eXBlIExPQ0tfVFlQRSB3aXRoIHRoZSBQT0lOVEVSIGF0dHJpYnV0ZSBiZQ0KcHJvaGli aXRlZD8NCg0KQU5TV0VSOg0KDQpJdCB3YXMgaW50ZW5kZWQgdGhhdCBjb21wb25lbnRzIG9mIHR5 cGUgTE9DS19UWVBFIG5vdCBiZSBwZXJtaXR0ZWQgdG8NCmhhdmUgdGhlIFBPSU5URVIgYXR0cmli dXRlLiAgRWRpdHMgYXJlIHByb3ZpZGVkIHRvIGNvcnJlY3QgdGhpcyBtaXN0YWtlLg0KDQpFRElU UzoNCg0KWzM5OToxOCtdIDEzLjguMi4xNiBMT0NLX1RZUEUsIGFmdGVyIEMxMzAyLCBpbnNlcnQg bmV3IGNvbnN0cmFpbnQNCiAgIkMxMzAyYSBBIGNvbXBvbmVudCBvZiB0eXBlIExPQ0tfVFlQRSwg b3IgdGhhdCBoYXMgYSBub25hbGxvY2F0YWJsZQ0KICAgICAgICAgZGlyZWN0IGNvbXBvbmVudCBv ZiB0eXBlIExPQ0tfVFlQRSwgc2hhbGwgbm90IGhhdmUgdGhlDQogICAgICAgICBQT0lOVEVSIGF0 dHJpYnV0ZS4iLg0KDQpTVUJNSVRURUQgQlk6IFZhbiBTbnlkZXINCg0KSElTVE9SWTogMTQtMTQw ICAgIG0yMDQgIEYwOC8wMTE0IHN1Ym1pdHRlZA0KICAgICAgICAgMTQtMTQwcjEgIG0yMDQgIFJl dmlzZWQgdG8gcmV2ZXJzZSBkZWNpc2lvbg0KICAgICAgICAgMTQtMTQwcjIgIG0yMDQgIFBhc3Nl ZCBieSBKMyBtZWV0aW5nDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_004_4AA982B1265F43408480F737BE12F4D35F93010CORSMSX103amrcor_--