J3/15-006
To: J3
From: Stan Whitlock
Subject: Outstanding Fortran Interpretations before m206
Date: 2015 Feb 09

      Outstanding Fortran Interpretations, February 9, 2015

                  Stan Whitlock for /interp

> 05-015             == closed F95 interps
> 016 = 10-006T1-5r1 == F03 Corrigenda 1-5 interps
> 017 = N1823        == F03 combined corrigenda 1-5
> 019 = N2005        == F08 combined corrigenda 1-3
> 020 = N2006        == F08 Corrigenda 1-3 interps

> m205 J3 LB #31 14-233r1/14-258: 3 of 5 passed
> m205: 10 of 11 new + 2 old interps passed J3 meeting
+ m206: WG5 ballot #8: N2042/43/47 - 10 of 10 passed by WG5 ballot
+ m206: 14-279/15-121 LB #32 - 12 of 12 passed by J3 ballot
= 12 passed J3 LB, 10 passed WG5, 15 J3 in progress

[keep this text document to 75 characters per line] ....................4

Table of Contents

Part 0 contains the summary status of all of the Fortran
       interpretations

Part 1 contains the interpretation processing rules from 00-142

Part 2 contains active F90/F95 interpretations:

       - only F90/0145
       - the F95 interps numbered F95/1-32 and 66-104 are all closed

Part 3 contains active F03 interpretations: F03/0001-0141

Part 4 contains active F08 interpretations: F08/0001...

======================================================================
Part 0: Summary Status of these Fortran Interpretations
======================================================================

Note N:
     d == done {if S = C* | T*, then done is assumed}
     * == active

Status S:                              Defect Type T:
       P == J3 consideration in progress           C == Clarification
       M    Passed by J3 meeting                   E    Erratum
       B    Passed by J3 letter ballot             I    Interpretation
       W    Passed by WG5 ballot
       X    Excluded for the reasons given
       C1   In F2008 Corrigendum 1
       C2   In F2008 Corrigendum 2
       C3   In F2008 Corrigendum 3

N  S T number     title
-  - - ------     -----

*  P E F90/0145   Expressions in <type-spec> of a FUNCTION statement
------
d C2 I F03/0017   Dummy procedure pointers and PRESENT
d C2 C F03/0018   Multiple identical specific procedures in
                   type-bound generic interfaces
d C2 E F03/0019   Multiple identical specific procedures in
                   generic interface blocks
d C2 E F03/0021   What kind of token is a stop code?
d C3 E F03/0030   IEEE divide by zero
*  P E F03/0042   IEEE funny values and Standard real generic
                    intrinsic procedures
d C2 C F03/0046   Unlimited polymorphic pointers in
                   common blocks
d C3 I F03/0047   Polymorphic arguments to intrinsic
                   procedures
d C1 E F03/0048   Control edit descriptors in UDDTIO
*  P I F03/0051   Repeat specifiers and UDDTIO
d C3 E F03/0053   The BIND attribute for C_PTR and C_FUNPTR
*  P E F03/0059   Structure components in namelist input
d C3 E F03/0064   Recursive declaration of procedure interfaces
d C2 I F03/0065   Relational equivalence
*  P I F03/0084   IEEE_SET_ROUNDING_MODE in a subroutine
d C1 E F03/0085   Finalizing targets of pointer or allocatable
d C1 I F03/0091   Array components cannot depend on length type
                   parameters
d C2 E F03/0096   Can a read statement change the unit value?
d C3 E F03/0100   Error in field width for special cases of signed
                   INFINITY output
d C2 E F03/0103   Restrictions on dummy arguments not present for
                   polymorphic type or parameterized derived type
d C1 I F03/0105   SIZE= specifier and UDDTIO
d C1 I F03/0110   Restoring dropped restriction on ENTRY
d C2 I F03/0116   indistinguishable specifics for a generic
                   interface with use association
d C2 E F03/0118   Are lower bounds of assumed-shape arrays assumed?
d C2 E F03/0120   When are parameterized sequence types the same
                   type?
*  P C F03/0121   Precise FP semantics of the REAL intrinsic
d C1 I F03/0123   Implicit typing in derived types
d C1 E F03/0124   definition is poorly defined
d C1 I F03/0128   Subobjects in namelist output
d C3 E F03/0139   Functions returning procedure pointers
------
d C1 E F08/0001   Generic resolution with pointer dummy arguments
d C1 E F08/0002   Are assumed- or deferred-shape objects allowed in
                   namelist?
d C1 E F08/0003   Is a disassociated pointer allowed as an actual
                   DIM argument?
d C2 E F08/0004   Is TARGET argument of ASSOCIATED a pointer or
                   nonpointer dummy?
d C1 E F08/0005*  optional arguments and ASSOCIATED - subsumed by
                   F08/0004
d C1 I F08/0006   generic resolution with banned argument
                   combinations
d C1 I F08/0007   Can zero have more than one bit sequence
                   representation?
d C2 I F08/0008   IEEE exceptions for intrinsic functions
d C1 I F08/0009   Is ABS ever required to be the optional IEC
                   60559 abs?
d C1 E F08/0010   deallocating objects that are associated with
                   other objects
d C1 E F08/0011   How many times are constructed values finalized?
d C1 E F08/0012*  Are constants finalized? - subsumed by F08/0011
d C1 E F08/0013   How does finalization interact with allocatable
                   assignment?
d C1 E F08/0014   Finalizing assignment to vector-subscripted
                   object
d C1 E F08/0015   IMPLICIT
d C1 E F08/0016   Can a vector-subscripted argument become undefined?
d C1 E F08/0017   Elemental subroutine restrictions
d C1 E F08/0018   Impure elemental restrictions
d C1 E F08/0019   Transformational Bessel functions
d C1 E F08/0020   FINDLOC and logical arguments
d C1 E F08/0021   STORAGE_SIZE and unlimited polymorphic
d C1 E F08/0022   DO CONCURRENT and file i/o
d C1 E F08/0023   DO CONCURRENT and POINTER
d C1 E F08/0024   Dummy arguments of impure elemental procedures
d C1 E F08/0025   DO CONCURRENT and ALLOCATABLE
d C1 E F08/0026   DO CONCURRENT and output interleaving
d C1 E F08/0027   ATOMIC_REF example
d C1 E F08/0028   Does a procedure reference cause loop termination?
*  P E F08/0029   G0 edit descriptor and floating-point output
d C1 E F08/0030   Unlimited format repeat effects
d C2 E F08/0031   PURE INTENT(OUT) finalization
d C2 E F08/0032   PURE FUNCTION result finalization
d C1 E F08/0033   PURE polymorphic finalization
d C1 E F08/0034   ELEMENTAL INTENT(OUT) finalization
d C1 I F08/0035   Maximum value for SHIFT argument to SHIFTL
                   and SHIFTR
d C1 E F08/0036   NORM2 example in Annex C
d C1 E F08/0037   PROCEDURE POINTER vs PROTECTED
d C2 C F08/0038   Are pointless restrictions on DIM arguments
                   intended?
d C1 E F08/0039   Many-one vector subscript usage
d C2 E F08/0040   MOVE_ALLOC for coarrays
*  P E F08/0041   Segment ordering rules
d C2 E F08/0042   SOURCE= questions
d C2 E F08/0043   Executing a type-bound procedure on a coindexed
                   object
d C1 I F08/0044   Resolving the type of a coarray or coindexed object
*  P E F08/0045   constraints on entities of type LOCK_TYPE
d C1 E F08/0046   VALUE attribute restrictions
d C1 I F08/0047   public generic with same name as private type
d C2 E F08/0048   Sequence association for coarrays
d C1 E F08/0049   ELEMENTAL functions with nonconstant type parameters
d C1 E F08/0050   Ordering requirements on definition of specification
                   functions
d C1 E F08/0051   Pure procedure arguments with VALUE
d C1 E F08/0052   Private type-bound procedures
d C1 E F08/0053   Restrictions on generic declarations, generic
                   resolution
d C2 E F08/0054   Requirements for needing an explicit interface
d C2 E F08/0055   G editing for reals
d C2 E F08/0056   Non-polymorphic ALLOCATE with polymorphic SOURCE=
d C2 E F08/0057   Interoperability with empty types
d C2 E F08/0058   ENTRY point RESULT variable
d C2 E F08/0059   Auto-targetting requirements
d C2 E F08/0060   Procedure pointer assignment with an EXTERNAL target
d C2 E F08/0061   Description of the CONTIGUOUS attribute misworded?
d C2 C F08/0062   Mixing default initialization with DATA
                   initialization
d C2 I F08/0063   G editing to a narrow output field
d C2 E F08/0064   STATUS of GET_ENVIRONMENT_VARIABLE
d C2 E F08/0065   Should certain procedures in intrinsic modules be
                   pure?
d C2 E F08/0066   Are certain expressions with pointer initialization
                   constant?
d C2 E F08/0067   Passing arrays of extended type objects
d C2 E F08/0068   Pointer association and extended type arrays
d C2 E F08/0069   Which part of an effective argument becomes
                   undefined?
d C2 E F08/0070   Finalization of INTENT(OUT) arguments
d C3 E F08/0071   Vector subscript target
d C2 E F08/0072   Final subroutines with corank
d C2 E F08/0073   Polymorphic auto-targetting
d C2 E F08/0074   Implicit type in BLOCK construct
d C3 E F08/0075   Pointer function reference as variable in assignment
d C3 E F08/0076*  Pointer function reference in READ
                   Subsumed by F08/0075 == W
d C2 E F08/0077   Function references as variables in DATA statements
d C2 E F08/0078   Are the IEEE values +0 and -0 distinguished
d C2 E F08/0079   NAMELIST and type specification
d C2 E F08/0080   Array constructors with polymorphic values
d C2 E F08/0081   Deallocation error handling
d C2 E F08/0082   Generic identifier and dtv arguments
d C3 E F08/0083   Type parameter default expressions allow circular
                   dependence
d C3 E F08/0084   Pointer arguments to PURE functions
d C3 E F08/0085   Problems with PARAMETERs
d C3 E F08/0086   Implied-shape and separate PARAMETER statement
d C3 E F08/0087   Mixed-kind character assignment
d C3 E F08/0088   Can ALLOCATE with SOURCE= have side-effects in a
                   PURE proc?
*  P E F08/0089   Variable-denoting functions change existing
                   semantics
d C3 E F08/0090   What restrictions apply to initialization and
                   PARAMETER?
d C3 E F08/0091   Derived type with no components
d C3 E F08/0092   Derived type parameter requirements
d C3 E F08/0093   Process exit status and error termination
d C3 E F08/0094   Procedure statement and double colon
d C3 E F08/0095   Is PRESENT allowed in specification and constant
                    expressions
d C3 E F08/0096   Is VALUE permitted for an array in a BIND(C)
                    procedure?
d C3 E F08/0097   Is the optional comma allowed in
                    TYPE(CHARACTER*...)?
d C3 E F08/0098   How many ACQUIRED_LOCK= specifiers are allowed in a
                    LOCK stmt?
*  W I F08/0099   VOLATILE in specification expressions
*  W E F08/0100   IMPORT statement and prior explicit declaration
*  W E F08/0101   NAMELIST and multiple occurrences of a variable
*  W E F08/0102   MERGE and polymorphism
*  W E F08/0103   Pointers to internal procedures with different host
                    instances
*  W E F08/0104   IEEE Inquiry Functions
*  B I F08/0105   Is the ASYNCHRONOUS attribute allowed with the
                    VALUE attribute?
*  W E F08/0106   MOVE_ALLOC for a remote array
*  P E F08/0107   LOCK_TYPE, ultimate components, subcomponents, and
                    coarrays
*  W I F08/0108   ultimate components and coarrays
*  P E F08/0109   LOCK_TYPE and unlimited polymorphic
*  B E F08/0110   Interdependence of specifier values in input/output
                    statements
*  P E F08/0111   Undefinition
*  W E F08/0112   STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
*  W E F08/0113   Specifiers in image control statements
*  P E F08/0114   Can LOCK_TYPE components have the POINTER attribute?
*  B E F08/0115   ASYNCHRONOUS and argument passing
*  B E F08/0116   Interoperable procedures
*  B E F08/0117   TARGET and coindexed arguments
*  B E F08/0118   Subobject of variable in variable definition context
*  B E F08/0119   Branching to END BLOCK and END CRITICAL
*  B E F08/0120   Is the name of a procedure pointer a local identifier?
*  B E F08/0121   Add to introduction defined operations in specification
                   exprs
*  B E F08/0122   Types with coarray components
*  B E F08/0123   SPACING intrinsic
*  B E F08/0124   Coindexed object with polymorphic subcomponent
*  P E F08/0125   Definition of objects of type LOCK_TYPE with pointer
                   subobjects

======================================================================
Part 1: Interpretation Processing Rules
======================================================================

0. All interpretations are listed in J3 standing document 006.

1. Interpretations are processed by the J3/interp group and given a
   number.  The interpretation is marked "J3 consideration in
   progress".  An answer is formulated and presented to J3 in a
   meeting paper.

2. J3 votes on the answer at a J3 meeting; a simple majority vote
   marks the answer as "passed by J3 meeting".

3. 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.

4. The chair of J3/interp gathers all interp answers that are marked
   "passed by J3 letter ballot" and forwards them to the WG5
   convenor.  The WG5 convenor holds a ballot of individual members;
   a no vote must be accompanied by an explanation of the changes
   necessary to change the member's vote to yes.  The answers that
   pass this ballot become "WG5 approved".

   J3/interp reserves the right to recall an interp answer for more
   study even if the answer passes.

5. "WG5 approved" answers are processed into a corrigendum document
   by taking the edits from the interp answers and putting them in
   the format required by ISO.  A WG5 vote is made on forwarding the
   corrigendum to SC22.  Interps so forwarded are marked
   "Corrigendum".

6. J3/interp creates a edit for the next Fortran Standard if one is
   needed for all interps marked "Corrigendum".

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

======================================================================
Part 2: Active F90/F95 interpretations
======================================================================

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

NUMBER: F90/0145
TITLE: Expressions in <type-spec> of a FUNCTION statement
KEYWORDS: expression - specification, expression - initialization,
          FUNCTION statement, host association, use association
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

The syntax rule R1217 shows that the type and type parameters of a
function can be specified in the FUNCTION statement (12.5.2.2).

(a) If a <type-spec> appears in a FUNCTION statement, can the
initialization and specification expressions of that <type-spec>
involve names of entities that are declared within the function or
are accessible there by host or use association?

(b) Section 5.1 states:

      "The <specification-expr> (7.1.6.2) of a <type-param-value>
       (5.1.1.5) or an <array-spec> (5.1.2.4) may be a nonconstant
       expression provided the specification expression is in an
       interface body (12.3.2.1) or in the specification part of a
       subprogram."

As a FUNCTION statement is not part of the specification part of a
subprogram, this text in the standard appears to distinguish between
FUNCTION statements that are in interface blocks and ones that are
not. This text seems to prohibit such examples as:

         INTEGER I
          ...
         CONTAINS
           CHARACTER*(I+1) FUNCTION F()
              ...
              COMMON // I
              ...

where it can be confusing as to which I is being referenced in the
FUNCTION statement.  While host association does not apply to
interface bodies, for consistency should the text quoted from Section
5.1 have been "... is in the specification part of an interface body
(12.3.2.1) or in the specification part of a subprogram."?

(c) Section 7.1.6.1 states:

      "If an initialization expression includes a reference to an
       inquiry function for a type parameter or an array bound of an
       object specified in the same <specification-part>, the type
       parameter or array bound must be specified in a prior
       specification of the <specification-part>."

Was this text intended to apply to FUNCTION statements even though
they are not part of any <specification-part>, thus disallowing
fragments such as:

      INTEGER (KIND=KIND(X)) FUNCTION F()
        INTEGER(KIND=KIND(0)) X
        ...

Similar text appears in Section 7.1.6.2.

ANSWER:

(a) A specification expression in the <type-spec> of a FUNCTION
statement may involve names of entities that are declared within the
function or are accessible there by host or use association, but an
initialization expression in such a <type-spec> may only involve
names that are accessible by host or use association.

(b) No.  It was not the intent of the standard to distinguish between
the two types of FUNCTION statements cited.  As elaborated in the
discussion of part (a), the standard intended to allow the
<type-spec> expression of a FUNCTION statement to be a nonconstant
expression.  The sentence cited is corrected with a supplied edit.

(c) Yes, the text cited from 7.1.6.1 was intended to apply to
FUNCTION statements.  The sentence quoted and the corresponding
sentence in 7.1.6.2 are corrected with supplied edits.  The code
fragment is not standard conforming.

Discussion:

(a) An initialization expression is a constant expression with an
additional rule relating to exponentiation (7.1.6.1).  Since it is a
constant expression, the only names it can contain are the names of
named constants, structure constructors, intrinsic procedures, and
variables whose type parameters or bounds are inquired about.

    * Named constant

      Section 5.1.2.1 states:

       "A named constant must not be referenced in any ... context
        unless it has been defined in a prior PARAMETER statement or
        type declaration statement using the PARAMETER attribute, or
        made accessible by use association or host association."

      Since the FUNCTION statement is the first statement of the
      scoping unit, there can be no prior PARAMETER statement or type
      declaration statement using the PARAMETER attribute, so the
      first clause does not apply. A named constant can appear in a
      <type-spec> of a function statement if it is accessible within
      the function by host or use association.

    * Structure constructor

      Rule R502 shows that the only opportunities for expressions to
      appear in <type-spec>s are in a <kind-selector> or in a
      <char-selector>.  However, a structure constructor can not
      appear in a <kind-selector> because rule R505 shows that a
      <kind-selector> must be an integer expression.  Similarly, R506
      shows that any initialization expression in a <char-selector>
      must be type integer.  Therefore, a structure constructor can
      not appear in an initialization expression in the <type-spec>
      of a FUNCTION statement.

    * Intrinsic procedure

      The intrinsic procedure names or classes of intrinsic
      procedures that may appear in an initialization expression are
      given in 7.1.6.1.

    * Variables whose type parameters or bounds are inquired about

      The text from section 7.1.6.1 as cited in question (c) was
      intended to apply to initialization expressions in the
      <type-spec> of a FUNCTION statement.  With the correction
      supplied, this means that if a variable appears as the argument
      to an inquiry intrinsic in the <type-spec> of a FUNCTION
      statement, the function must be a module procedure or an
      internal procedure, and the variable must exist in (be
      accessible from) the host scoping unit.

Rule R502 defines <type-spec>.  The only opportunity for a
<type-spec> to contain a <specification-expr> is when the data type
is character (<type-param-value> may be a <specification-expr>).
Section 7.1.6.2 states that a specification expression is a
restricted expression that is scalar, of type integer, and each
operation must be intrinsic.  In addition, rule (2) of 7.1.6.2 states
that a primary of a specification expression can be a dummy argument
that has neither the OPTIONAL nor INTENT(OUT) attribute.  The
following code fragment demonstrates a use of such a dummy argument:

              CHARACTER*(N+1) FUNCTION S(N)
              INTEGER, INTENT(IN) :: N

Rule (2) also states that the primary can be a subobject of such a
dummy argument.  Section 6.1.2 indicates that a structure component
must not be referenced or defined before the declaration of the
parent object.  Similar rules are needed to prevent a substring from
being referenced ahead of the declaration of its parent, and an array
element or array section from being referenced ahead of the
declaration of the array.  Edits are provided to supply these rules.
Since a subobject can not be referenced before its parent object is
declared and the FUNCTION statement is the first statement of the
subprogram, the parent's declaration could not have occurred.  Thus a
subobject must not be referenced in the <type-spec> on a FUNCTION
statement for objects declared within the function.

Rule (3) states that a primary can be a variable that is in a common
block.  The following code fragment demonstrates a use of such a
common block member:

              CHARACTER*(N+1) FUNCTION S()
              ...
              COMMON N

As in rule (2), rule (3) allows a subobject of such a variable but
for the same reasons as above, such a subobject designator can not
appear in the <type-spec> expression of a FUNCTION statement.

Rule (4) states that a primary may be a variable that is accessible
by use association or host association.  The following code fragments
demonstrate uses of such variables:

              PROGRAM MAIN
              INTEGER :: N = 21
              ...
              CONTAINS
                CHARACTER(LEN = 2*N) FUNCTION SS(K)    ! N is host
                ...                                    !  associated.
                END FUNCTION
              END PROGRAM

    and

              MODULE MOD
              INTEGER K
              DATA K /20/
              END MODULE

              CHARACTER*(K*2) FUNCTION CHECK(STR)      ! K is use
                                                       !  associated.
              USE MOD
              ...
              END FUNCTION

Rule (4) also states that the primary can be a subobject of such a
use or host associated variable.

A structure constructor can not appear in a FUNCTION <type-spec>
specification expression because the expression must be of type
integer and any operations (which might yield an integer value from
one or more structure constructors) must be intrinsic.

Other rules of 7.1.6.2 state which intrinsic procedure names or
classes of intrinsic procedures may appear in a specification
expression.

Section 7.1.6.2 also states:

        A variable in a specification expression must have its type
        and type parameters, if any, specified by a previous
        declaration in the same scoping unit, or by the implicit type
        rules currently in effect for the scoping unit, or by host or
        use association.

The discussion above regarding specification expressions has already
ruled out "previous declarations" so the first clause of the cited
sentence does not apply.  The other clauses apply equally to a
FUNCTION statement <type-spec> and to type declaration statements
inside the function.

(b) When the discussion for part (a) is applied to the code fragment
provided, it means that the 'I' referenced in the <type-spec> of the
FUNCTION statement is the common block member.

EDITS:
1. Section 5.1, in the first sentence of the paragraph that starts
   "The <specification-expr> (7.1.6.2)" [40:39-41],

    change "in an interface body (12.3.2.1) or in the specification
            part of a subprogram"

       to  "contained in an interface body (12.3.2.1), is contained
            in the specification part of a subprogram, or is in the
            <type-spec> of a FUNCTION statement (12.5.2.2)"

2. Section 6.1.1, add to the end of the paragraph before the examples
[62:29]

    "A substring must not be referenced or defined before the
     declaration of the type and type parameters of the parent string,
     unless the type and type parameters are determined by the
     implicit typing rules of the scope."

3. Section 6.2.2, add after the sentence "An array section is an
array." [64:16]
           "An array element or array section must not be referenced
            or defined before the declaration of the array bounds."

4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22]

    change "object specified in the same <specification-part>, the
             type parameter or array bound must be specified in
             a prior specification of the <specification-part>."

    to     "object declared in the same scoping unit, the type
            parameter or array bound must be specified in a
            specification prior to the initialization expression."

5. Section 7.1.6.2, in the 2nd paragraph after the constraint
[79:28-29]

    change "entity specified in the same <specification-part>, the
             type parameter or array bound must be specified in
             a prior specification of the <specification-part>."

    to     "entity declared in the same scoping unit, the type
            parameter or array bound must be specified in a
            specification prior to the specification expression."

SUBMITTED BY: Janice C. Shepherd

HISTORY: 93-193   m126  F90/0145 submitted
         94-023r1 m128  response, approved uc
         94-116r1 m129  X3J3 ballot failed 22-1
         94-336   m131  revised response, approved u.c
         95-034r1 m132  X3J3 ballot failed 15-5
         95-281   m135  revised response, reworded edit 3, WG5
                         approved (N1161)
         96-      m136  X3J3 ballot failed 15-1, WG5 approval removed.

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

======================================================================
Part 3: Active Fortran 2003 Interpretation Requests
======================================================================

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

NUMBER: F03/0030
TITLE:  IEEE divide by zero
KEYWORDS: IEEE-754, divide-by-zero
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Is infinity / 0.0 a divide by zero exception?
Is NaN / 0.0 a divide by zero exception?

Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero
cases as IEEE_DIVIDE_BY_ZERO.  IEEE-754 defines (in 6.1 and 6.2)
those two as unexceptional.

ANSWER:

On an IEEE-conformant processor, these cases do not raise exceptions
(see clauses 6.1 and 6.2 of IEC 60559:1989).

The definitions in 14.2 were intended to describe IEC 60559:1989
exceptions with sufficient latitude to allow use on machines that do
not conform to IEC 60559:1989.  However, the definition of
IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989.

Furthermore, the definition of the IEEE_OVERFLOW flag is also not
consistent with IEC 60559:1989, because this exception is not raised
for operations on infinite operands.

Additionally, if the data type is not an IEEE data type, but the
exception is supported, the circumstances under which the exception is
raised are processor dependent.

Edits are provided.

EDITS to 10-007r1:

[403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW),
  Replace with
  "IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction,
   multiplication, division, or conversion by the intrinsic function
   REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is
   true for the operands of the operation or conversion, and as
   determined by the processor otherwise.  It occurs in an intrinsic
   real exponentiation as determined by the processor.  It occurs in a
   complex operation, or conversion by the intrinsic function CMPLX,
   if it is caused by the calculation of the real or imaginary part of
   the result."

[403:10-11] Clause 14.3, first paragraph, second bullet
  (IEEE_DIVIDE_BY_ZERO),
  Replace with
  "IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC
   60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the
   division, and as determined by the processor otherwise.  It is
   processor-dependent whether it occurs in a real exponentiation with
   a negative exponent.  It occurs in a complex division if it is
   caused by the calculation of the real or imaginary part of the
   result."

[462:24+] Clause A.2, after the fifth bullet from the end of the clause
  "the extent to which a processor supports IEEE arithmetic (14)",
  Insert new bullet points
  "- the conditions under which IEEE_OVERFLOW is raised in a
     calculation involving non-IEC 60559:1989 floating-point data;
   - the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO
     are raised in a floating-point exponentiation operation;
   - the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a
     calculation involving non-IEC 60559:1989 floating-point data;"

SUBMITTED BY: Fred Tydeman

HISTORY: 05-109    m171  F03/0030 submitted
         05-109r1  m171  Revised to include IEEE_OVERFLOW,
                         Passed by J3 meeting
         05-170    m172  Passed J3 letter ballot #11
         N1622     m172  Failed WG5 ballot N1629
         10-238r1  m193  Revised answer - Passed J3 meeting
         11-129    m194  Passed as amended by J3 letter ballot
                          #22 10-254
         11-006Ar1 m196  Adjust edits to reference 10-007r1
         N1878     m196  Failed WG5 ballot 1 N1876
         13-246    m200  Revised - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F03/0042
TITLE:  IEEE funny values and Standard real generic intrinsic
        procedures
KEYWORDS: IEEE-754, real math library
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Is an infinite result from an infinite argument to a real math
function exceptional (raises an exception)?

Is a NaN result from a NaN argument to a real math function
exceptional (raises an exception)?

What are the results (value and exceptions) for the following
(section 13.7.*) real math library functions [suggested results
for most are included; no exception happens unless specified]:

 ABS(-0.0) returns +0.0
 ABS(+/-infinity) returns +infinity
 ABS(NaN) returns a NaN

 ACOS(x), where |x|>1, returns a NaN and raises invalid
 ACOS(NaN) returns a NaN

 AINT(-0.0) returns -0.0
 AINT(NaN) returns a NaN
 AINT(+infinity) returns +infinity
 AINT(-infinity) returns -infinity

 ANINT(-0.0) returns -0.0
 ANINT(NaN) returns a NaN
 ANINT(+infinity) returns +infinity
 ANINT(-infinity) returns -infinity

 ASIN(x), where |x|>1, returns a NaN and raises invalid
 ASIN(NaN) returns a NaN

 ATAN(-0.0) returns -0.0
 ATAN(+infinity) returns +pi/2
 ATAN(-infinity) returns -pi/2
 ATAN(NaN) returns a NaN
 ATAN2(NaN,x) returns a NaN
 ATAN2(y,NaN) returns a NaN
 ATAN2(+/-0.0, -0.0) returns +/-pi (and not raise invalid)
 ATAN2(+/-0.0, +0.0) returns +/-0.0 (and not raise invalid)
 ATAN2(+/-0.0, x) returns +/-pi for x < 0.0
 ATAN2(+/-0.0, x) returns +/-0.0 for x > 0.0
 ATAN2(y, +/-0.0) returns -pi/2 for y < 0.0
      (and not raise divide by zero)
 ATAN2(y, +/-0.0) returns +pi/2 for y > 0.0
      (and not raise divide by zero)
 ATAN2(+/-y, -infinity) returns +/-pi for finite y > 0.0
 ATAN2(+/-y, +infinity) returns +/-0.0 for finite y < 0.0
 ATAN2(+/-infinity, x) returns +/-pi/2 for finite x
 ATAN2(+/-infinity, -infinity) returns +/-3pi/4
      (and not raise invalid)
 ATAN2(+/-infinity, +infinity) returns +/-pi/4
      (and not raise invalid)

 CEILING(+/-infinity) returns +/-infinity
 CEILING(-0.0) returns -0.0
 CEILING(NaN) returns a NaN

 COS(+/-0.0) returns 1
 COS(NaN) returns a NaN
 COS(+/-infinity) returns a NaN and raises invalid

 COSH(+/-0.0) returns 1
 COSH(NaN) returns a NaN
 COSH(+/-infinity) returns a +infinity DIM(NaN,y) returns a NaN

 DIM(x,NaN) returns a NaN
 DIM(+/-0.0, +/-0.0) returns a +0.0
 DIM(+infinity, -infinity) returns a NaN and raises invalid
 DIM(+infinity, +infinity) returns +0.0
 DIM(-infinity, -infinity) returns +0.0
 DIM(-infinity, +infinity) returns +0.0

 DPROD(NaN,y) returns a NaN
 DPROD(x,NaN) returns a NaN
 DPROD(+/-0.0, +/-infinity) returns a NaN and raises invalid
 DPROD(+/-infinity, +/-0.0) returns a NaN and raises invalid
 DPROD(+/-infinity, +/-infinity) returns an infinity with its sign
 being the XOR of the arguments, and raises no exceptions.
 DPROD(+/-0.0, +/-0.0) returns a zero with its sign
 being the XOR of the arguments, and raises no exceptions.

 EXP(NaN) returns a NaN
 EXP(+/-0.0) returns 1
 EXP(-infinity) returns +0.0
 EXP(+infinity) returns +infinity

 EXPONENT(+/-0.0) returns 0 [should be -HUGE(0)] and raises invalid
 EXPONENT(NaN) returns HUGE(0) and raises invalid
 EXPONENT(+/-INF) returns HUGE(0) and raises invalid
 EXPONENT(denormal) returns the value as if the number were
         normalized and the exponent range were unbounded
 If /e/ is not representable as a default integer, invalid is raised
   and sign(/e/)*HUGE(0) should be returned.

 FLOOR(NaN) returns a NaN
 FLOOR(-0.0) returns -0.0
 FLOOR(+/-infinity) returns +/- infinity

 FRACTION(-0.0) returns -0.0
 FRACTION(NaN) returns a NaN
 FRACTION(denormal) returns the value as if the number were
         normalized and the exponent range were unbounded
 FRACTION(+/-infinity) returns +/- infinity

 INT(NaN) returns an unspecified value and raises invalid
 INT(+/-infinity) returns an unspecified value and raises
    invalid
 INT(+/-large), where large cannot be represented as an integer,
    returns an unspecified value and raises invalid

 LOG(+/-0.0) returns -infinity and raises divide-by-zero
 LOG(NaN) returns a NaN
 LOG(1.0) returns +0.0
 LOG(x), for x < 0, returns a NaN and raises invalid
 LOB(+infinity) returns +infinity

 LOG10(+/-0.0) returns -infinity and raises divide-by-zero
 LOG10(NaN) returns a NaN
 LOG10(1.0) returns +0.0
 LOG10(x), for x < 0, returns a NaN and raises invalid
 LOG10(+infinity) returns +infinity

 MAX(NaN,NaN) returns a NaN
 MAX(NaN,y) returns y [some say it should be NaN]
 MAX(x,NaN) returns x [some say it should be NaN]
 MAX(-0.0,+0.0) returns +0.0
 MAX(-0.0,-0.0) returns -0.0
 MAX(+infinity,y) returns +infinity
 MAX(-infinity,y) returns y

 MIN(NaN,NaN) returns a NaN
 MIN(NaN,y) returns y [some say it should be NaN]
 MIN(x,NaN) returns x [some say it should be NaN]
 MIN(-0.0,+0.0) returns -0.0
 MIN(-0.0,-0.0) returns -0.0
 MIN(-infinity,y) returns -infinity
 MIN(+infinity,y) returns y

 MOD(NaN,y) returns a NaN
 MOD(x,NaN) returns a NaN
 MOD(+/-infinity,y) returns a NaN and raises invalid
 MOD(+/-infinity,+/-infinity) returns a NaN and raises invalid
 MOD(x,+/-0.0) returns a NaN and raises invalid
 MOD(+/-0.0,+/-0.0) returns a NaN and raises invalid

 MODULO(NaN,y) returns a NaN
 MODULO(x,NaN) returns a NaN
 MODULO(+/-infinity,y) returns a NaN and raises invalid
 MODULO(+/-infinity,+/-infinity) returns a NaN and raises invalid
 MODULO(x,+/-0.0) returns a NaN and raises invalid
 MODULO(+/-0.0,+/-0.0) returns a NaN and raises invalid

 NEAREST(NaN,y) returns a NaN
 NEAREST(x,NaN) returns a NaN
 NEAREST(x,+/-0.0) returns a NaN and raises invalid  [why???]
 NEAREST(+infinity,+num) returns +infinity ???
 NEAREST(+infinity,-num) returns +maximum finite number
 NEAREST(-infinity,+num) returns -maximum finite number
 NEAREST(-infinity,-num) returns -infinity ???

 NINT(NaN) returns an unspecified value and raises invalid
 NINT(+/-infinity) returns an unspecified value and raises
     invalid
 NINT(+/-large), where large cannot be represented as an
     integer, returns an unspecified value and raises invalid

 RRSPACING(NaN) returns a NaN
 RRSPACING(+/-infinity) returns +/-infinity
          [differs from current F2003]
 RRSPACING(+/-0.0) returns +0.0
 RRSPACING(+/-denormal) returns ???

 SCALE(NaN,y) returns a NaN
 SCALE(+/-infinity,y) returns +/-infinity
 SCALE(-0.0,y) returns -0.0

 SET_EXPONENT(NaN,y) returns a NaN
 SET_EXPONENT(+/-infinity,y) returns +/-infinity
 SET_EXPONENT(-0.0,y) returns -0.0
 SET_EXPONENT(denormal,y) returns ???

 SIGN(NaN,y), where 0 < y, returns the same NaN,
      but with the sign bit cleared.
 SIGN(NaN,y), where y < 0, returns the same NaN,
      but with the sign bit set.

 SIN(NaN) returns a NaN
 SIN(+/-infinity) returns a NaN and raises invalid
 SIN(-0.0) returns -0.0

 SINH(NaN) returns a NaN
 SINH(+/-infinity) returns +/- infinity
 SINH(-0.0) returns -0.0

 SPACING(NaN) returns a NaN
 SPACING(+/-infinity) returns +infinity
 SPACING(-0.0) returns TINY(+0.0)
 SPACING(denormal) returns TINY(+0.0) ???

 SQRT(NaN) returns a NaN
 SQRT(+infinity) returns +infinity
 SQRT(-0.0) returns -0.0
 SQRT(x), where x < 0.0, returns a NaN and raises invalid

 TAN(NaN) returns a NaN
 TAN(+/-infinity) returns a NaN and raises invalid
 TAN(-0.0) returns -0.0

 TANH(NaN) returns a NaN
 TANH(+/-infinity) returns +/-1.0
 TANH(-0.0) returns -0.0


13.7 [300:13-15] incorrectly requires an infinite result or a
NaN result to always signal some IEEE exception.

Consider changing [300:13] "infinite result" to "infinite result
(from finite arguments)".  Reason: IEEE-754 mathematical
operations on infinity that produce an infinity are
unexceptional.

Consider changing [300:14] "NaN result" to "NaN result (from
non-NaN arguments)".  Reason: IEEE-754 mathematical operations
on quiet NaN operands that produce a quiet NaN result are
unexceptional.

Consider adding to 13.7 [300:15+] something along the lines of:
"Unless specified otherwise, a math function with NaN
argument(s) shall return a NaN, which should be one of the NaN
arguments."  This allows not having to specify the results for
each specific math function.

Consider adding the above suggested cases to each of the 13.7.*
functions, perhaps, with a bold face IEEE sub-heading.

ANSWER:

The penultimate sentences of 13.7 was intended for the case
where all arguments on entry have normal or denormal values
and edits are supplied to correct this.

To specify the results of all the intrinsics for non-normal
values is beyond the scope of an interpretation. Perhaps this
should be considered for an extension that is adopted for the
next revision of the standard. Meanwhile, guidance is provided
by the second and third paragraphs of 14.8, which state

"The inquiry function IEEE_SUPPORT_NAN is provided to inquire
whether the processor supports IEEE NaNs. Where these are supported,
their behavior for unary and binary operations, including
those defined by intrinsic functions and by functions in intrinsic
modules, shall be consistent with the specifications in the IEEE
International Standard.

The inquiry function IEEE_SUPPORT_INF is provided to inquire whether
the processor supports IEEE infinities. Where these are supported,
their behavior for unary and binary operations, including
those defined by intrinsic functions and by functions in intrinsic
modules, shall be consistent with the specifications in the IEEE
International Standard. "


EDITS:

Page and line numbers refer to 04-007.

[300:13&14] Subclause 13.7. In the penultimate sentence, replace
"If" by "If the values of all input arguments are normal or
denormal and" and replace "if" by "if the values of all input
arguments are normal or denormal and"

SUBMITTED BY: Fred Tydeman

HISTORY: 05-121r1  m171  F03/0042 submitted

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

NUMBER: F03/0047
TITLE: Polymorphic arguments to intrinsic procedures
KEYWORDS: polymorphism, intrinsic procedures
DEFECT TYPE: Interpretation
STATUS: No edits in F2008 Corrigendum 3

QUESTION:

The descriptions of the intrinsic procedures often use the term "type"
without qualification.  It is unclear whether they mean "declared
type" or "dynamic type".  If they mean "dynamic type", then this would
appear to allow unlimited polymorphic arguments to intrinsic
procedures like ABS and SIN.  Resolution of generic intrinsic
procedures in this case would create an undue (and likely unintended)
burden on the processor, and the declared type of the result of such a
function call would be unclear as well.

Question 1:
Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED,
LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic?

Question 2:
(a) Is the ARRAY argument of the intrinsic function CSHIFT permitted
    to be polymorphic?
If so:
(b) If the argument is polymorphic, is the result polymorphic?  What
    are the declared and dynamic types of the result?

Question 3:
(a) Are the ARRAY and BOUNDARY arguments of the intrinsic function
    EOSHIFT permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, then must the other be
    polymorphic?
(c) Do the requirements on their types refer to their declared types
    or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic? What
    are the declared and dynamic types of the result?

Question 4:
(a) Are the A and MOLD arguments of the intrinsic function
    EXTENDS_TYPE_OF permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
    polymorphic?
(c) Do the requirements on their types refer to their declared types
    or dynamic types?

Question 5: This question is deferred to interp F08/0102.
(a) Are the TSOURCE and FSOURCE arguments of the intrinsic function
    MERGE permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
    polymorphic?
(c) Do the requirements on the types of the arguments refer to their
    declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
    What are the declared and dynamic types of the result?

Question 6:
Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC
permitted to be polymorphic?

Question 7:
(a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK
    permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
    polymorphic?
(c) Do the requirements on the types of the arguments refer to their
    declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
    What are the declared and dynamic types of the result?

Question 8:
(a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE
    permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
    polymorphic?
(c) Do the requirements on the types of the arguments refer to their
    declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
    What are the declared and dynamic types of the result?

Question 9:
(a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS
    permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
    polymorphic?
(c) Do the requirements on their types refer to their declared types
    or dynamic types?

Question 10:
(a) Is the SOURCE argument of the intrinsic function SPREAD permitted
    to be polymorphic?
If so:
(b) If the argument is polymorphic, is the result polymorphic?  What
    are the declared and dynamic types of the result?

Question 11:
(a) Is the SOURCE argument of the intrinsic function TRANSFER
    permitted to be polymorphic?
(b) Is the MOLD argument of the intrinsic function TRANSFER permitted
    to be polymorphic?
If the answer to (b) is yes:
(c) If the MOLD argument is polymorphic, is the result polymorphic?
    What are the declared and dynamic types of the result?

Question 12:
(a) Is the MATRIX argument of the intrinsic function TRANSPOSE
    permitted to be polymorphic?
If so:
(b) If the argument is polymorphic, is the result polymorphic?  What
    are the declared and dynamic types of the result?

Question 13:
(a) Are the VECTOR and FIELD arguments of the intrinsic function
    UNPACK permitted to be polymorphic?
If so:
(b) If one of these arguments is polymorphic, must the other be
    polymorphic?
(c) Do the requirements on the types of the arguments refer to their
    declared types or dynamic types?
(d) If either argument is polymorphic, is the result polymorphic?
    What are the declared and dynamic types of the result?

Question 14:
Are any of the other arguments of any intrinsic procedure permitted to
be polymorphic?

ANSWER:

The assertion that it is unclear whether "type" means declared, dynamic,
or both, is misguided.  The general rule is that wherever it makes
sense, it means both.  Where only one meaning makes sense, it means
that one.  Where only one meaning is intended but it would otherwise
not be clear from context, it is qualified as "declared type" or
"dynamic type".

Answer 1:
Yes.

Answer 2:
(a) Yes.
(b) Yes.  "The result is of the type ... of ARRAY".

Answer 3:
(a) Yes.
(b) No.
(c) The requirements apply to both the declared type and the dynamic
    type.
(d) "The type has ... the type ... of ARRAY".  Therefore it is polymorphic
    if ARRAY is polymorphic.

Answer 4:
(a) Yes.
(b) No.
(c) The requirements refer to the declared type; this is explicitly
    stated.

Answer 5:  This question has been deferred to interp F08/0102
   TSOURCE and FSOURCE are required have the same declared type, but may
   be polymorphic.  The questions of what the requirements are on the
   dynamic type, and whether the result is polymorphic, are deferred to
   interp F08/0102.

Answer 6:
Yes.

Answer 7:
(a) Yes.
(b) No.
(c) The requirements refer to both the declared type and the dynamic
    type.  Note that this means that if either ARRAY or VECTOR is not
    polymorphic, the requirement for type matching means that the
    dynamic type of the polymorphic argument is known.
(d) The result "has the same type" as ARRAY, and therefore is polymorphic
    if ARRAY is polymorphic.

Answer 8:
(a) Yes.
(b) No.
(c) The requirements refer to both the declared type and the dynamic
    type.
(d) The result "has the same type" as SOURCE, and therefore is polymorphic
    if and only if SOURCE is polymorphic.

Answer 9:
(a) Yes.
(b) No.
(c) The requirements are explicitly stated to refer to the declared type.

Answer 10:
(a) Yes.
(b) Yes.  "The result is ... of the same type ... as ARRAY.".

Answer 11:
(a) Yes.
(b) Yes.
(c) "The result is of the same type ... as MOLD.".

Answer 12:
(a) Yes.
(b) Yes.  The declared and dynamic types of the result are those of
    the argument.

Answer 13:
(a) Yes.
(b) Yes.
(c) The requirements refer to both the declared type and the dynamic
    type.
(d) Yes.  The result has the same declared and dynamic types as VECTOR,
    and is polymorphic if and only if VECTOR is polymorphic.

Answer 14:
Yes.  For example, IMAGE_INDEX, LCOBOUND, PRESENT, STORAGE_SIZE, and
UCOBOUND.

EDITS:

None.

SUBMITTED BY: Rob James

HISTORY: 05-138    m171  F03/0047 submitted - contained the
                          questions/answers
         05-138r1  m171  Contained the edits, passed by J3 meeting
         05-170    m172  Passed J3 letter ballot #11
         N1622     m172  Failed WG5 ballot N1629
         13-242    m200  Revised - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed as amended by WG5 ballot 6 N1987/88/90
** Q5 was deferred to F08/0102; A2(b) and A13(d) were modified
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F03/0051
TITLE: Repeat specifiers and UDDTIO
KEYWORDS: repeat specifier, POS=, UDDTIO
DEFECT TYPE: Interpretation
STATUS: J3 consideration in progress

QUESTION:

Consider the following program:

MODULE m

  TYPE t
    INTEGER :: i
    INTEGER :: j
  END TYPE

  INTEGER :: ipos

  INTERFACE READ(FORMATTED)
    MODULE PROCEDURE formattedReadT
  END INTERFACE

CONTAINS

  SUBROUTINE formattedReadT (dtv, unit, iotype, vlist, iostat, iomsg)
    CLASS(T), INTENT(INOUT) :: dtv
    INTEGER, INTENT(IN) :: unit
    CHARACTER(*), INTENT(IN) :: iotype
    INTEGER, INTENT(IN) :: vlist(:)
    INTEGER, INTENT(OUT) :: iostat
    CHARACTER(*), INTENT(INOUT) :: iomsg

    READ(unit, *) dtv%i
    INQUIRE(unit, POS=ipos)
    READ(unit, *) dtv%j
  END SUBROUTINE

END MODULE

PROGRAM foo
  USE m
  TYPE(t) :: a
  OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted')
  WRITE(10, '(A)') '2*3 5'
  REWIND(10)
  READ(10, *) a
  PRINT *, a%i, a%j, ipos
END PROGRAM

10.9 of Fortran 2003 states that the r*c form of list-directed input
is equivalent to r occurrences of c.  So, when the read is performed,
it is as if the input record contains two occurrences of the number 3.

The first child read statement reads the first 3, and does not advance
the file position to the next record (because it is a child data
transfer statement).  It appears that the second read statement should
read the second 3.  But the file position between the child read
statements is unclear.

What does the above program print?

ANSWER:

The standard does specify the behavior of a processor when a list
directed input record contains a r*c constant, but that is irrelevant
to the question at hand.  Executing an INQUIRE statement using an
internal unit is prohibited by [235:16] 9.10.2.1p2.  The program does
not conform.

EDITS:

None.

SUBMITTED BY: Rob James

HISTORY: 05-142        m171  F03/0051 submitted
         05-142r2      m171  Passed by J3 meeting
         05-167/170    m172  Failed J3 letter ballot #11
         06-369r1      m178  Passed by J3 meeting
         07-250r1/272  m181  Failed J3 letter ballot #13
         13-248        m200  Revised - withdrawn

The question raised at m200 was about the definition of "internal unit
(9.6.4.8.3)" [226:4], which seems to conflict with the Terms and
Definitions [12:26-31]:

    1.3.94
     internal file
      character variable that is connected to an internal unit (9.4)

    1.3.95
     internal unit
      input/output unit that is connected to an internal file (9.5.4)

The clarification we needed but couldn't find is probably [208:8-10]:

    An internal unit is used to refer to an internal file and is
    specified by an internal-file-variable or a file-unit-number
    whose value is equal to the unit argument of an active defined
    input/output procedure (9.6.4.8).

/Stan

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

NUMBER: F03/0053
TITLE: The BIND attribute for C_PTR and C_FUNPTR
KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute?

This affects whether an object of one of these types is permitted
directly in COMMON.  C5101 in the Fortran 2008 standard states "If a
common-block-object is of a derived type, it shall be a sequence type
or a type with the BIND attribute and it shall have no default
initialization."

2. Whether the derived types C_PTR and C_FUNPTR have the BIND
attribute affects whether they are extensible.  Subclause 4.5.7.1 of
the Fortran 2008 standard states "A nonsequence derived type that does
not have the BIND attribute is an extensible type."  Are these types
extensible?

3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and
C_FUNPTR are derived types with private components. Are user-defined
derived types with the BIND attribute permitted to have private
components?

ANSWER:

1. No, these types do not have the BIND attribute.  15.3.3 does not
specify that they have the BIND attribute.  15.3.4 does not require
them to have the BIND attribute in order to make them interoperable.
15.3.5 would require them to interoperate with a C struct if they had
the BIND attribute; this is absurd, since C object pointers and C
function pointers are clearly not structs.

Note that whether these types have default initialization is not
specified by the standard, so possession of BIND would not necessarily
have allowed them in COMMON anyway.

Edits are provided to correct incomplete, and thus misleading,
statements about derived types and the BIND attribute.

2. No, these types were not intended to be extensible.  It was an
oversight that these types were not explicitly excluded from being
extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008
standard.  An edit is provided to correct this.

3. Yes, a user-defined derived type with the BIND attribute is
permitted to have private components.  This situation is the same
as for SEQUENCE types, which are similar (but not interoperable).
As with SEQUENCE types, making a component PRIVATE does prevent
access, in a conforming program, to the component by a programmer who
is sufficiently determined; however, it continues to fulfill the
software engineering role for which it was intended.  Note further
that there are many other situations where two different Fortran
derived types will interoperate with the same C derived type; this is
not a defect in either standard, but simply a consequence of the two
languages having different approaches to type compatibility.

EDITS to 10-007r1:

[19:15-16] In 1.3.147.6,
  replace the definition of "extensible type"
  with "type that may be extended using the EXTENDS clause (4.5.7.1)".
{Repair definition of extensible type.}

[77:3] In 4.5.7.1p1,
  After "A derived type" insert
    ", other than the type C_PTR or C_FUNPTR from the intrinsic module
     ISO_C_BINDING,"
{Prohibit these types from subsequent extension.}

[431:6] In 15.3.4p1, replace the first sentence with
  "Interoperability between derived types in Fortran and struct types
   in C is provided by the BIND attribute on the Fortran type."
{Reduce misleading opening blather - this is just here so we didn't
 start the subclause with a bunch of constraints.  Alternatively we
 could move paragraph 2 (and note 15.12) to replace paragraph 1.}

[431:12+2] In 15.3.4, Note 15.11,
  After "is interoperable" insert "with a C struct type".
{Correct another misleading sentence.}

[431:13-18] In 15.3.4p2,
  Change all four occurrences of "Fortran derived type"
  to "derived type";
  change the single occurrence of "Fortran type" to "derived type".
{Remove unnecessary and confusing qualification of "derived type" with
 "Fortran".}

SUBMITTED BY: John Reid

HISTORY: 05-151    m171  F03/0053 submitted - Passed by J3 meeting
         05-170    m172  Passed J3 letter ballot #11
         N1622     m172  Failed WG5 ballot N1629
         11-217r1  m195  Revised answer for Fortran 2008 - Passed
                          by J3 meeting
         11-241    m196  Passed as amended by J3 letter ballot
                          #24 11-229
         12-165r2  m198  Passed by J3 letter ballot #25 12-147
         12-193    m199  Failed WG5 ballot #3 N1932/N1933/N1939
         12-190    m199  Revised answer/edits - passed by J3 meeting
         13-237    m200  Passed as amended by J3 letter ballot
                           #27 13-203
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F03/0059
TITLE: Structure components in namelist input
KEYWORDS: Namelist, UDDTIO, component
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Consider the following program:

      MODULE m
        PRIVATE
        TYPE, PUBLIC :: t
          INTEGER :: i
          INTEGER :: j
        CONTAINS
          PROCEDURE, PRIVATE :: readFormatted => readFormattedT
          GENERIC :: READ(FORMATTED) => readFormatted
        END TYPE
      CONTAINS
        SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, &
                                 & iomsg)
          CLASS(t),     INTENT(INOUT) :: dtv
          INTEGER,      INTENT(IN)    :: unit
          CHARACTER(*), INTENT(IN)    :: iotype
          INTEGER,      INTENT(IN)    :: v_list(:)
          INTEGER,      INTENT(OUT)   :: iostat
          CHARACTER(*), INTENT(INOUT) :: iomsg
          READ (unit, *) dtv%i
          dtv%j = dtv%i * 2
        END SUBROUTINE
      END MODULE

      PROGRAM p
        USE m
        TYPE(t) :: x
        NAMELIST /nml/ x
        READ (*, nml)
        PRINT *, x%i, x%j
      END PROGRAM

Question 1:
Is the following input valid for the above program?

&nml
 x%i = 100
/

Question 2:
If the input is valid, what is the output of the program, when using
this input?

ANSWER:

1. No, this input is not valid for the given program.  The name of a
component of a structure should not appear in namelist input if that
structure would be processed by a user-defined derived-type I/O
procedure.  Edits are supplied to correct this oversight.

2. N/A

EDITS:

[243:24-27]
Replace
    "If the namelist group object name is the name of a variable of
     derived type, the name in the input record may be either the name
     of the variable or the designator of one of its components,
     indicated by qualifying the variable name with the appropriate
     component name."
with
    "If the namelist group object is a variable of derived type, the
     name in the input record may be the name of the variable.  If the
     variable would not be processed by a user-defined derived-type
     input/output procedure, the name in the input record may also be
     the designator of one of its components, using the syntax of
     object designators."

SUBMITTED BY: Rob James

HISTORY: 05-174    m172  F03/0059 submitted
         05-221    m173  Passed by J3 meeting
         06-133    m175  Failed J3 letter ballot #12 - typo fixed

  Rich Bleikamp's NO comment for F03/0059:

    The replacement text reads "if the variable would not be processed
    by a UDDTIO ...", but I think the presence of an object designator
    might actually determine whether or not the object designator is
    processed by a UDDTIO routine (sort of the reverse decision
    process than what is being suggested, where being processed by a
    UDDTIO routine precludes the use of a non-simple variable name in
    the input record).

    Second, the sentence immediately after the replaced text talks
    about "Successive qualifications" being applied to the name.  I
    think this reads awkwardly with the suggested edit.

    Third, I think the answer may be wrong.  For namelist input, we
    should allow (perhaps we already do) object designators all the
    time, and just not invoke the UDDTIO routine if the object
    designator is not a simple  variable name, or if the resulting
    objects datatype/shape do not match an existing interface for a
    UDDTIO routine.  Also, its not clear to me (its too late in the
    day), but perhaps we really want to allow an object designator
    that's an array element reference to invoke a UDDTIO routine.
    We could use the datatype and shape of the object designator to
    determine whether or not a UDDTIO routine should be invoked
    (still a compile time decision).  I'm not at all sure we'd want
    to allow component references in such a case, or perhaps a
    component reference in the input record just precludes the
    possibility of invoking a UDDTIO routine for that input value.

    The tradeoffs here are:
    1) allow some more functionality (which we may already allow),
       such as array element references appearing in a namelist input
       record (as a namelist group object name, possibly qualified),
       and still cause a UDDTIO routine to be invoked, and

    2) keep the rules simple enough that the user and compiler's I/O
      library can easily agree on what's supposed to happen, and
      what input values are therefore allowed.

    I was going to suggest a replacement edit, but my head hurts too
    much :).

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

NUMBER: F03/0064
TITLE: Recursive declaration of procedure interfaces
KEYWORDS: procedure, interface
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Q1. Consider the following program:

      PROGRAM foo
        PROCEDURE(sub) :: p
        INTERFACE
          SUBROUTINE sub(p2)
            IMPORT p
            PROCEDURE(p) :: p2
          END SUBROUTINE
        END INTERFACE
      END PROGRAM

C1216 appears to prohibit the case of an interface name in a procedure
declaration statement being the name of something declared in a later
procedure declaration statement.  But it does not appear to prohibit
the case of an interface name being the name of something declared in
a later interface body.

In the above program, the characteristics of p rely on the
characteristics of sub.  The characteristics of sub, in turn, rely on
the characteristics of p.

Is this program standard-conforming?

Q2. Consider the module

    MODULE m1
    CONTAINS
      SUBROUTINE s(p)
        PROCEDURE(s) :: p
      END SUBROUTINE
    END MODULE

Constraint C1216 does not apply here since "s" is not declared by a
procedure declaration statement; unlike Q1, it is also not declared by
an interface body.  However, the characteristics of S have not been
determined before the procedure declaration statement has been
processed, and that cannot be processed until we know what the
interface of S is.

Is this program unit standard-conforming?

Q3. Consider the module

    MODULE m2
    CONTAINS
      SUBROUTINE s1(a)
        PROCEDURE(s2) :: a
      END SUBROUTINE
      SUBROUTINE s2(b)
        PROCEDURE(s1) :: b
      END SUBROUTINE
    END MODULE

The interface of A depends on the interface of S2, which depends on
the characteristics of B, which depends on the characteristics of S1,
which depends on the characteristics of A; a circular dependency.

Is this program unit standard-conforming?

Q4. Consider

      MODULE m3
        PROCEDURE(s),POINTER :: sptr
      CONTAINS
        SUBROUTINE s(p)
          PROCEDURE(sptr) :: p
        END SUBROUTINE
      END MODULE

In the normal course of events there is no problem declaring a
procedure pointer to have the interface of a module procedure that is
defined later, and this is desirable, but in this case there seems to
be a circular dependency between the characteristics of sptr, s, and
p.

Is this program unit standard-conforming?

ANSWER:

None of the examples are standard-conforming, as the standard does not
establish an interpretation for them.

An edit is provided to clarify this.

EDIT to 10-007r1:

[288:3] 12.4.3.6p2, append new sentence
  "The interface specified by <interface-name> shall not depend on any
   characteristic of a procedure identified by a
   <procedure-entity-name> in the <proc-decl-list> of the same
   procedure declaration statement."

SUBMITTED BY: Rob James

HISTORY: 05-179    m172  F03/0064 submitted
         05-226    m173  Passed by J3 meeting
         06-133    m175  Failed J3 letter ballot #12
         09-149    m187  Passed by J3 meeting
         09-187r2  m188  Failed J3 letter ballot #18 09-155
         13-245    m200  Revised - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F03/0084
TITLE: IEEE_SET_ROUNDING_MODE in a subroutine
KEYWORDS: IEEE_ARITHMETIC
DEFECT TYPE: Interpretation
STATUS: J3 consideration in progress

QUESTION:

Section 7.1.7 of the Fortran 2008 standard says that if the value of an
expression can be determined before execution of the program, it is
standard-conforming to use the predetermined value.

Consider the subprogram

        SUBROUTINE S()
        USE, INTRINSIC :: IEEE_ARITHMETIC
        USE, INTRINSIC :: IEEE_FEATURES

        INTEGER, PARAMETER :: sp = IEEE_SELECTED_REAL_KIND(6,30)
        real(sp) :: X = 0.5559013_sp
        real(sp) :: Y = 1.2092481_sp
        real(sp) :: Z1, Z2
        IF (IEEE_SUPPORT_ROUNDING(IEEE_NEAREST,X) .AND. &
            IEEE_SUPPORT_ROUNDING(IEEE_UP,X)) THEN
            CALL IEEE_SET_ROUNDING_MODE(IEEE_UP)
            Z1 = X*Y
            CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST)
            Z2 = X*Y
            PRINT *, 'Residual: ', Z1 - Z2
        ENDIF
        END

(1) Is a processor permitted always to print zero for the residual
    Z1 - Z2 ?
(2) Same question, after giving X and Y the PARAMETER attribute.

ANSWER:

(1) Yes.  The processor is allowed to evaluate expressions (constant
or otherwise) in any mathematically equivalent way.  In particular, it
is permitted to evaluate using higher precision than any precision
available when the program is executed.  For example, it might compute
Z1 == Z2 == 0.67222259081253, then compute Z1 - Z2 == 0.0, regardless
of how the program might do rounding at the seventh decimal digit when
it is executed.

(2) Yes, for the same reasons as question (1).

EDITS to 10-007r1:

None.

SUBMITTED BY: Michael Ingrassia

HISTORY: 06-372    m178  F03/0084 submitted
         11-218    m195  Revised answer for Fortran 2008 - Passed
                          by J3 meeting
         11-241    m196  Passed as amended by J3 letter ballot
                          #24 11-229
         12-165r2  m198  Passed as amended by J3 letter ballot
                          #25 12-147
         12-193    m199  Failed WG5 ballot #3 N1932/N1933/N1939

F03/0084

Bader NO vote:

The answers given to both (1) and (2) in the interp appear to me
to be counterintuitive; the programmer would expect that the
calculation of Z1 and Z2 respectively obey the imposed rounding
mode. In particular, I suspect there are situations where it is
more obvious to the compiler than to the programmer that expressions
are evaluated at compile time, and that different processors may
have differing capabilities in identifying such expressions. The
resolution of such situations is one target that the IEEE facilities
were designed for. I therefore am in favor of the stance that, if
supported, the setting of the rounding mode should take precedence
over processor-dependent compile-time evaluations.

Corbett NO vote:

I disagree with the interpretation given.  I believe that the
assignments should require conversions to be done and that the
conversions should be done in accord with the rounding mode
currently in effect.  Therefore, the results should not be zero.

Long NO vote:

I was confused by John's comment that the rounding mode on
entry to the subroutine affected the value of Z1 since the computation
of Z1 follows a call that resets the rounding mode.  I think the real
question here is what the standard means by "mathematical".  I had
always thought in terms of things like algebra.  John's answer seems
to imply that computational numerics (as specified by IEEE) are part
of the concept of "mathematical".  In other contexts, I think that
John's interpretation could be harmful.  On the other hand, the
current answer does seem to make the usefulness of the
IEEE_SET_ROUNDING_MODE routine more limited that would be
expected. Also, does the concept of mathematically equivalent apply to
the aggregation of multiple statements, or does it apply to just one
expression?  A processor that used the "mathematically equivalent"
argument to get 0 would need to forward sub the expressions for Z1 and
Z2 into the print statement to get X*Y - X*Y.  I don't think we
intended to allow forward substitution of expressions across one of
the IEEE mode setting routines.

Maclaren comment:

This relates to F03/0065, but is the other way round.  Unlike that one,
I consider this consistent with the majority of the semantic wording in
the C standard.

Muxworthy No vote:

I agree with John's vote.

Reid NO vote:

The IEEE rounding mode on entry to the procedure may vary from
call to call. The value of Z1 depends on this rounding mode.
Therefore, the processor should not always print zero for Z1-Z2.
Whether or not Z1 and Z2 have the PARAMETER attribute makes no
difference. Yes, the processor is allowed to evaluate an
expression in any mathematically equivalent way, but here the
mathematics dictates that a particular form of rounding, defined
in the IEEE standard, be applied.

Snyder NO vote:

    The answer makes rounding mode changes pointless.

    The work-around usually advanced to cause rounding mode changes to
    have effect (but not advanced in the answer to the interpretation)
    is to store intermediate results that are computed with different
    rounding modes in VOLATILE variables if they are ultimately to be
    combined in a single expression.

    Subclause 5.3.19 states, in part, however, that "The VOLATILE
    attribute specifies that an object may be referenced, defined, or
    become undefined, by means not specified by the program."  Setting
    the rounding mode is done by means that ARE specified by the
    program, so the advice is not germane.  One who reads subclauses
    5.3.19, 14.4, 14.11.6, and 14.11.21, and the answer to this
    interpretation, might not realize that the use of VOLATILE variables
    is required, under the present interpretation, for subclauses 14.4,
    14.11.6, and 14.11.21 to be meaningful.

    A better answer would have been to amend 7.1.5.2.4 to require that
    all entities within the expression are evaluated with the same
    rounding mode, or to specify that quantities evaluated with
    different rounding modes cannot be considered to be mathematically
    equivalent, even if evaluated by textually identical expressions.
    This might require processors either to abandon certain
    optimizations, or to perform more detailed dataflow analysis that
    propagates rounding mode to determine when those optimizations are
    permitted.

    If the position implied by the answer to this interpretation is to
    be maintained, the absence of edits is entirely inadequate.  The
    definition of VOLATILE must be changed to encompass actions that ARE
    specified by the program, and to encompass advice concerning
    rounding mode changes.  Advice to store intermediate results that
    are computed with different rounding modes into VOLATILE variables,
    if they are to be combined in a single expression, must be included
    in subclauses 14.4 and 14.11.21.

    During the requirements phase for the 2008 standard, there was a
    request (in 04-219) for a "strict mode" similar to that described in
    section G.2 of the Ada standard, in which rounding mode settings
    would actually have an effect without needing to resort to VOLATILE
    variables.  If a "strict mode" had been provided, it might have made
    sense to allow a processor to ignore rounding mode changes outside
    strict regions.  A request for a "strict mode" will be presented
    during the requirements-gathering phase for the next revision of the
    standard, for this as well as other reasons.

......................................................................

F03/0084: Replies from the editor
    John Reid writes:
<<<
     The IEEE rounding mode on entry to the procedure may vary from
     call to call. The value of Z1 depends on this rounding mode.
     Therefore, the processor should not always print zero for Z1-Z2.
     Whether or not Z1 and Z2 have the PARAMETER attribute makes no
     difference. Yes, the processor is allowed to evaluate an
     expression in any mathematically equivalent way, but here the
     mathematics dictates that a particular form of rounding, defined
     in the IEEE standard, be applied.
>>>

No it does not.  IEEE peculiarities play no part in the mathematical
Reals.

IEEE is merely one form of computer arithmetic.  (It would make very
bad mathematics, since IEEE numbers are not even a subset of the
2-point compactification of the Reals, thus nearly all mathematical
identities and theorems about the Reals would get destroyed.)  Computer
arithmetic is *computational* not *mathematical*.  ALL computer
arithmetics frequently give different computational answers for
mathematically-equivalent expressions.

And I cannot believe you are again trotting out this nonsense saying
constant expressions should not be treated as constant.  If I have
   "REAL(KIND=INT(a+b)) :: x(INT(a+b)) = a+b; y=a+b",
with a and b being floating-point named constants, I am not allowed
to evaluate a+b at compile time?  Surely you jest.  Or I can in the
KIND= but not in the array bound?  Unless the array is in COMMON or
has the SAVE attribute?  Surely you jest even more.  Or I can
everywhere except in the "y ="?  You cannot be serious.

Furthermore, the rationale you are using is applicable to all routines
regardless of whether they call IEEE_SET_ROUNDING and would thereby
destroy many basic optimisations.  You.Really.Can.Not.Be.Serious.

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

NUMBER: F03/0100
TITLE: Error in field width for special cases of signed INFINITY
       output
KEYWORDS: formatted output, signed infinity
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Is there an error in the description for the output of a IEEE infinity
with a sign and a field width of 3 or 8?

Fortran 2008, 10.7.2.3.2 paragraph 7, [252:33-34], describes the
output of IEEE infinities; this specifies asterisks (field overflow) if
the field width is less than 3, and omission of "inity" if the field
width is less than 8.  However, this does not take into account the
fact that there might be a plus or minus sign in the field.

The current text also fails to take into account the case of <w> = 0,
for both Infinity and NaN values.

ANSWER:

Yes, there is an error in the special cases.  Edits are provided to
correctly describe the required field widths for signed infinities.
An edit is also provided to repair the description of the output of
NaN values.

EDITS to 10-007r1:

[252:33-34] 10.7.2.3.2p7, Replace "If <w> is ... produced." with

  "The minimum field width required for output of the form 'Inf' is 3
   if no sign is produced, and 4 otherwise.  If <w> is greater than
   zero but less than the minimum required, the field is filled with
   asterisks.  The minimum field width for output of the form
   'Infinity' is 8 if no sign is produced and 9 otherwise.  If <w>
   is greater than or equal to the minimum required for the form
   'Infinity', the form 'Infinity' is output.  If <w> is zero or <w>
   is less than the minimum required for the form 'Infinity' and
   greater than or equal to the minimum required for the form 'Inf',
   the form 'Inf' is output.  Otherwise, the field is filled with
   asterisks."

[252:37] Same subclause, p8, Replace "If <w> ... askerisks." with

  "If <w> is greater than zero and less than 3, the field is filled
   with asterisks.  If <w> is zero, the output field is 'NaN'.".

SUBMITTED BY: Dick Hendrickson

HISTORY: 07-271    m181  F03/0100 submitted
         07-271r2  m181  Passed by J3 meeting
         07-321    m182  Failed J3 letter ballot #14 07-279
         07-340r1  m182  Passed by J3 meeting
         08-133r2  m183  Passed by letter ballot #15 08-101
         08-164    m184  Failed WG5 ballot #5 N1722-N1726
         13-247    m200  Revised - passed by J3 meeting
         13-262    m201  Passed as amended by J3 letter ballot #28
                          13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F03/0121
TITLE: Precise FP semantics of the REAL intrinsic
KEYWORDS: REAL intrinsic
DEFECT TYPE: Clarification
STATUS: J3 consideration in progress

QUESTION:

Must the intrinsic function REAL with KIND parameter wp return a value
that is a REAL (KIND=wp) floating point number?

RATIONALE FOR THE QUESTION:

Computer hardware may use a wider floating-point format for registers
than for memory; e.g., 80 bits for registers and 64 bits for memory
for the case of standard double precision floating point numbers.
Some algorithms require a high level of control over floating point
semantics.  If the intrinsic function REAL with KIND parameter wp is
guaranteed to return a REAL (KIND=wp) result then a programmer can use
this to force intermediate results into main memory format, never mind
that the optimizing compiler may have placed the intermediate in a
register.

I am interested in a J3 interpretation of this matter, especially a
loud and clear affirmative interpretation, because it appears that
some present Fortran compilers optimize away my explicit use of the
REAL intrinsic.  The context is code for compensated summation (Kahan
summation).  I appreciate that parentheses are inviolable courtesy of
the Fortran standard, but in order to have code that cannot be broken
by an optimizing compiler I seem to need also a language mechanism to
force intermediate results into main memory format.

Bas Braams
Chemistry Department and
Emerson Center for Scientific Computation
Emory University
Atlanta, GA

ANSWER:

Yes, for purposes of determining the type and kind of the result, for
use in subclause 7.1.9.3, the result of the intrinsic function REAL with
KIND argument wp returns a value that is of type REAL(KIND=wp).
However, if it is used within an expression involving intrinsic
operations,
  "the processor may evaluate any mathematically equivalent
   expression, provided that the integrity of parentheses is not
   violated."
and
  "mathematically equivalent expressions of numeric type may produce
   different computational results",
which means that it is unlikely to serve your purpose.

Intermediate results can be rounded to storage format by assignment to a
VOLATILE variable.

EDITS to 10-007r1:

None.

SUBMITTED BY: Bas Braams, Emory University, Atlanta, GA

HISTORY: 08-208r1  m185  F03/0121 submitted
         10-240    m193  Draft answer for F2008 - Passed by J3 meeting
         11-129    m194  Passed by J3 letter ballot #22 10-254
         N1878     m186  Failed WG5 ballot 1 N1876
         11-260    m196  Revised answer
         11-260r1  m196  Passed by J3 meeting
         12-165r2  m198  Passed by J3 letter ballot #25 12-147
         12-193    m199  Failed WG5 ballot #3 N1932/N1933/N1939

F03/0121

Bader NO vote:

The answer as a whole seems misleading; given the specification
of the REAL intrinsic and existing rules for type conversions (or
their absence) in expressions, the answer should simply be "yes".
The reference to mathematically equivalent expressions is mostly
irrelevant (since by parenthesization the programmer's purpose
should very likely be achievable), and that to VOLATILE variables
is simply unnecessary.

Corbett NO vote:

I previously voted for the answer given.  Since then, I
have been convinced I was mistaken.  I no longer think
that REAL(X), where X has type REAL but has a different
kind type parameter value from that of type default real,
should be considered mathematically equivalent to X.  I
now agree with Mr. Braams that the intrinsic function REAL
should do a real conversion.

I agree with Van that nothing in the standard or in the
existing interpretations requires VOLATILE to force a
conversion.  Interpretation F90/000001 is the only
interpretation I have found that addresses the issue,
and it, of course, could not require the use of VOLATILE.
I agree with John that VOLATILE should not be required to
force a conversion.

Long NO vote:

Similar to F03/0084, this hinges on the meaning of "mathematical".
I'm not convinced that a processor is allowed to treat
X and REAL(X,wp) as mathematically equivalent.  The REAL function
(may) perform an operation that is outside the scope of normal
algebra.

Maclaren comment:

The recommendation to use VOLATILE is wrong.  There is a common myth in
among C and C++ programmers and even in informative text in the
standards that volatile implies this semantic, but it is not justified
by their normative text, nor do all compilers support it.  Fortran
should not follow suit - in particular, Fortran 2008 5.3.19 makes no
such guarantee.

In particular, because 5.3.19 provides licence to the processor and not
to the programmer, a compiler is at liberty to optimise all references
to VOLATILE variables if it does not provide any method of accessing it
other than those specified by the program.  Regrettably, the correct
response is:

   There is no feature in Fortran to provide this facility, though
   assignment to a VOLATILE variable will often work.  On some
   processors, making that a BIND(C) variable in a module will be
   needed but, on a few, this recipe will not work at all.

This should be addressed properly in a future revision.

Muxworthy comment:

Like Van, I find the Answer unsatisfactory although the outcome (no
edit) is correct.  The answer is Yes.  This is stated clearly in
13.7.138.  What a processor might or might not do behind the scenes is
irrelevant.  If it does not obey 13.7.138 it is non-standard-
conforming.  (We are talking about a high-level language, not C).

Reid NO vote:

I think it is unacceptable to recommend the use of the VOLATILE
attribute for a variable that is referenced, defined, or becomes
undefined only within the Fortran program. The desired effect
may be obtained by assigning the intermediate result to a
variable without the VOLATILE attribute because this rules out
the exceptions explained in the final sentence of the first
paragraph of the answer ("Furthermore, ...").

Snyder NO vote:

    The answer refers to subclause 7.1.5.2.4 without identifying that
    subclause: "the processor may evaluate any mathematically
    equivalent expression, provided that the integrity of parentheses is
    not violated," and uses that as justification for the answer.
    Subclause 7.1.5.2.4 is entirely irrelevant to the question.

    Subclause 4.1.2 specifies that "For each type there is a set of
    valid values."  Subclause 4.2 specifies that "the set of values...
    depend[s] on the values of the parameters."

    Subclause 13.7.2, as amended by the answer to interp F08/0008,
    says, in part, "A program shall not invoke an intrinsic procedure
    under circumstances where a value ... returned as a function result
    is not representable by objects of the specified type and type
    parameters."

    Allowing the REAL intrinsic function to return a result that is
    claimed to have a specified kind, and a value that is not a member
    of the set of valid values for that kind, violates the requirements
    of subclauses 4.1.2, 4.2, and 13.7.1 as amended by interpretation
    F08/0008.  An interpretation should not introduce an inconsistency
    that will later need to be resolved by yet another interpretation.
    Even if F08/0008 were to fail, the result of the answer to this
    interpretation would be to introduce a conflict to 13.7.1 status quo
    ante, which reads, in part, "A program is prohibited from invoking
    an intrinsic procedure under circumstances where a value to be
    returned in a subroutine argument or function result is outside the
    range of values representable by objects of the specified type and
    type parameters," and continues with caveats not germane to the
    present interpretation.

    The only reason ever to invoke the REAL intrinsic function with a
    real argument and a KIND argument is to produce a result with the
    specified kind, and a value that is a member of the set of valid
    values for that kind.  This is exceedingly rare, except perhaps as
    an actual argument (where the processor must necessarily produce a
    value that is a member of the set of valid values, and additionally
    is represented by the specified type and kind), and therefore
    requiring processors to produce a value for the result of REAL that
    is a member of the set of valid values for the kind of the result
    would have no measurable effect on performance in any program other
    than an arcane SPEC benchmark.

    The answer should be "Although a processor is allowed to replace an
    expression with a mathematically equivalent expression, subclauses
    4.1.2, 4.2, and 13.7.1 (or 13.7.1 as amended by interpretation
    F08/0008) require the value of the result of every intrinsic
    function to be a member of the set of valid values for the type and
    kind of the function result."  No normative edits would be required,
    although it would be helpful to add a recommendation in a note (or a
    requirement) to 13.7.138p5 Case (i) that the result have a value
    that is not different from the argument by more than one unit in its
    least significant place (unless the argument is NaN), and that it be
    rounded according to IEC 60559:1989 and the rounding mode currently
    in effect if the IEEE_ARITHMETIC module is accessible (unless the
    argument is NaN).

    Advice in the presently proposed answer is offered to use the
    VOLATILE attribute.  Subclause 5.3.19 states, in part, however,
    that "The VOLATILE attribute specifies that an object may be
    referenced, defined, or become undefined, by means not specified by
    the program."  Invoking the REAL intrinsic function is a means that
    IS specified by the program, so the advice is not germane.

    One who reads subclauses 4.1.2, 4.2, 5.3.19, 7.1.5.2.4 and 13.7.1
    would have no clue that the way to make REAL operate as essentially
    all users expect it to operate is to store its result into a
    variable that has the VOLATILE attribute!  If one must have the
    presently proposed answer, having no edits is entirely inadequate.
    Subclause 5.3.19 must be amended to include effects that ARE
    specified by the program.  Subclauses 5.3.19 and 13.7.138 must be
    amended to include advice to use the VOLATILE attribute to make REAL
    function as essentially all users expect it to.  Further, there must
    be an explicit exemption for REAL in subclause 13.7.1, and maybe in
    4.1.2 and 4.2 as well.

    A perverse reading of 13.7.1, adroitly sidestepping subclauses 4.1.2
    and 4.2, might be that a function is allowed to return a value that
    is not a member of the set of valid values for the type and kind of
    the result, but that a program is not allowed to invoke the function
    in such a way as to produce that result.  This would make it illegal
    instead of pointless to invoke the REAL intrinsic function with the
    hope to produce a value that is a member of the set of valid values
    for the kind of the result.  That is, for example, that REAL is
    permitted to act consistently with the present answer to this
    interpretation, but a program is not permitted to invoke
    REAL(3.14159265358979323846264338d0,kind(1.0e0)) if the processor
    uses 32-bit IEEE arithmetic for default real, because the result
    would not be a member of the set of valid values.  If so, in order
    to detect programs that are not standard conforming, a helpful
    processor should announce an error in this circumstance, which
    requires producing a value that is a member of the set of valid
    values, and comparing it to the proposed result value instead of
    using it as the result value.  One might argue that 13.7.1 was
    aimed, for example, at SQRT(-1.0), for which the mathematical
    function approximated by the intrinsic function has no values that
    are representable by the type and kind of the result.  But it
    doesn't say so, and that argument does not reasonably apply to
    REAL.  Since 13.7.138p5 Case (i) explicitly says that REAL produces
    an approximation to its argument, it is more reasonable for
    REAL(3.14159265358979323846264338d0,kind(1.0e0)) to produce an
    approximation that is a member of the set of valid values for the
    kind of the result, than for its invocation to be prohibited, or for
    it to produce a result that is not a member of the set of valid
    values for the kind of the result.

    If a processor absolutely must reduce REAL with a real argument to
    the identity operation under certain circumstances, a command-line
    argument to cause this behavior could be provided, with a caveat
    that using that setting admits behavior that is not consistent with
    the standard.

....................................................................

F03/0121: Replies from the editor

<<<
      I think it is unacceptable to recommend the use of the VOLATILE
      attribute for a variable that is referenced, defined, or becomes
      undefined only within the Fortran program. The desired effect
      may be obtained by assigning the intermediate result to a
      variable without the VOLATILE attribute because this rules out
      the exceptions explained in the final sentence of the first
      paragraph of the answer ("Furthermore, ...").
>>>

Well no.  Inter-statement optimisation is alive and well (re, in spite
of F90/000001: some vendors have to compete on SPEC benchmarks and the
like!), and the people moaning about the REAL() intrinsic not doing
what they want frequently also want the optimisation cranked up to that
level. In that case, VOLATILE is something that does, in fact, work.

One might plausibly argue that we are being more helpful here than we
need to.

Nick opined:
<<<
   ... is a common myth in among C and C++ and even in informative text
   in the standards that volatile implies this semantic
>>>

If informative text in the standard implies this semantic, that is a
clear indication of the intent of the C committee.

<<<
   but it is not justified by their normative text,
>>>

That is your opinion.  You might or might not be right.  My
understanding of the normative text is otherwise i.e. the same as the
informative implication.  I might or might not be right.  Under the
circumstances, since this is the Fortran committee not the C
committee, we should take the informative text as being correct
rather than what some of the barracks-room lawyers say.

<<<
   nor do all compilers support it
>>>

Many compilers have many bugs in many areas, and volatile is no
exception to this.  Indeed, papers have been written on such very
topics.  However, this case is very simple (no multi-threading
required!) and in my experience it does work reliably.

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

NUMBER: F03/0139
TITLE: Functions returning procedure pointers
KEYWORDS: procedure pointer
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

(1) Is a function permitted to return a procedure pointer?
    Much of the language talks about the function result variable,
    but a procedure pointer is not a variable.  For example, 2.2.3
    says [12:16]
       "The VARIABLE that returns the value of a function is called
        the RESULT VARIABLE."
    (emphasis mine); which indicates that the value of a function is
    returned in a variable.

(2) Where may a function reference that returns a procedure pointer
    appear?  In particular,
    (a) as a <selector> in a SELECT TYPE or an ASSOCIATE statement;
    (b) within parentheses as a primary;
    (c) as the argument to an intrinsic inquiry function such as
        KIND or LEN.

(3) [12:18-19] says
      "a subroutine may be used to change the program state by
       changing the values of any of the data objects accessible
       to the subroutine".
    A procedure pointer is not a data object, so is this meant to
    imply that a subroutine is not permitted to change the state of a
    procedure pointer?  Similar text for functions appears in the same
    paragraph.

ANSWER:

(1) Yes, a function is permitted to return a procedure pointer; the
     text calling this a variable is in error.  Edits are supplied to
     correct these mistakes.

(2) It was intended that a function reference that returns a
     procedure pointer only be permitted as an argument to the
     ASSOCIATED and NULL intrinsic functions and in places where an
     ordinary procedure name would be acceptable.  Parentheses around
     a pointer act to dereference the pointer and return a copy of the
     value: this action is inapplicable to procedures. Thus the
     answers to the specific sub-questions are No, No, and No again.
     Clarifying edits are provided.

(3) No, this implication is not intended.  A clarifying edit is
    provided.

EDITS for (1b):

[10:33+] Insert new term after "1.3.77 <<function>>"
  "1.3.77a <<function result>>
   entity that returns the value of a function".

[15:31-33] Delete term 1.3.121 <<result variable>>.

[52:2] 4.3.1.2p2, after "function result" delete "variable".

[58:23] 4.4.3.2p5,
        "result variable in the function" -> "function result".

[87:9] 5.1p2 "its result variable" -> "the function result".

[109:24] 5.5p4,
         "name of the result variable of that function subprogram"
         -> "result of that function".
{Function *subprogram*s do not have results, the function specified by
 the FUNCTION statement does, as do the ones defined by the ENTRY
 statements, but the subprogram is just syntax.}

[112:15] 5.7.1.1 C587, "result variable" -> "function result".

[114:22] 5.7.2.1 C5100, "result variable" -> "function result".

[130:26] 6.7.3.2p2, after "function result" delete "variable".

[278:11] 12.3.1 "result value"->"function result".
{Reads a bit awkwardly, but it is important to use the correct terms
 and to be consistent with 12.3.3 (which does) otherwise this is
 undefined meaningless blather.}

[307:5,9] 12.6.2.2p3, "result variable" -> "function result", twice.

[307:12,14,15] p4, "result variable" -> "function result", thrice.

[307:15-16] Delete "The characteristics ... variable.".

[307:16-17] "its result variable." -> "its function result."

[307:17] "is a pointer" -> "is a data pointer".

[307:18,18,20] "result variable" -> "function result", thrice.

[307:20+2] NOTE 12.41, "The ... subprogram." ->
  "The function result is similar to any other entity (variable or
   procedure pointer) local to the function subprogram.".
[307:20+4] "this variable" -> "this entity".
[307:20+5] "that variable" -> "that entity".

[309:23,24] 12.6.2.5p3,
            "result variable name" -> "name of the function result",
            twice.

[310:2] 12.6.2.6p3, after "name of its result" delete "variable".

[310:2-3] Delete "The characteristics ... the result variable.".

[310:5-6] "result variables identify the same variable"
          -> "result names identify the same entity"
           and delete ", although their names need not be the same".

[310:6] "scalars" -> "scalar variables".

[314:3] After "The result" delete "variable".

[433:7] "result variable is a scalar"->"result is a scalar variable".

[441:7,10] 16.3.1p4, "result variable" -> "function result", twice.

[441:18-20] 16.3.3p1, "result variable" -> "function result", thrice.

[449:3-4] 16.5.3.1p1 "result variables" ->
          "function results that are variables".

[450:20] 16.5.3.4p6,
         "result variables" -> "function results that are variables".

[456:11] 16.6.6p1, item (15)(e),
         "the result variable of a function"
         -> "a variable that is the function result of that procedure"
{Also fixes all function results becoming undefined when a single
 procedure is invoked!}

EDITS for (2b).

[133:26+] Insert new constraint
  "C702a (R701) The <expr> shall not be a function reference that
         returns a procedure pointer."

[170:23+] Insert new constraint
  "C804a (R805) The <expr> shall not be a function reference that
         returns a procedure pointer."

[316:12+] 13.2.1 after p6, insert new paragraph
  "An argument to an intrinsic procedure other than ASSOCIATED, NULL,
   or PRESENT shall be a data object."

EDITS for (3).

[30:28] After "data objects" insert "or procedure pointers".

SUBMITTED BY: Malcolm Cohen

HISTORY: 09-295    m190  F03/0139 submitted - Passed by J3 meeting:
                          B answers passed
         10-105    m191  Passed as amended by J3 letter ballot #20
                          09-307
         N1816     m191  Failed WG5 ballot #7 {N1805/6} - interp
                          updated - see 10-135r1
         13-249    m200  Revised - passed by J3 meeting
         13-262    m201  Passed as amended by J3 letter ballot #28
                          13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
** Add extra edit to [307:16-17];  change the edit for [433:7]
         N2002     m203  In F2008 Corrigendum 3

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

======================================================================
Part 4: Active Fortran 2008 Interpretation Requests
======================================================================

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

NUMBER: F08/0029
TITLE: G0 edit descriptor and floating-point output
KEYWORDS: G edit descriptor, 0 width
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

For data types other than floating-point, the effect of the G0 edit
descriptor is precisely defined.  For floating-point output, the
effect is precisely defined only if the value is an IEEE NaN or
Infinity, the result is otherwise left up to the processor to select
"reasonable" values for w, e, and d (if d is unspecified).

The standard states [258:7-9 10.7.5.2.2p2]:

      "the G0 and G0.d edit descriptors follow the rules for the
       Gw.dEe edit descriptor, except that any leading or trailing
       blanks are removed".

One might deduce from the wording of this that there is no upper limit
on the choice of w, since the production of additional leading (or
trailing) blanks has no effect on the output.

Q1. Is a value for w or e that results in the field being filled with
    asterisks reasonable?  This is not, after all, an error condition.

Q2. Is a value for d that results in significant loss of precision
    reasonable?  E.g. d==1, or for a less extreme example,
    d==PRECISION(value)/2.

Q3. Is a value for d that produces many more digits than the precision
    reasonable?  E.g. d==1000000.  Or, for a less extreme example,
    d==PRECISION(quad) with a single precision value.

Q4. Is a value for e that produces many more digits in the exponent
    than the exponent range reasonable?  E.g. e==1000000.

Q5. If the standard cannot tell me what "reasonable" means, what
    purpose does it serve for it to say that it must be reasonable?
    I cannot see how to tell whether a processor conforms to the
    standard in this respect.

DISCUSSION:

The standard permits, but does not require, the "best" values of w, d
or e to be chosen for each internal value.

ANSWER:

A1. No, that is not reasonable.  An edit is supplied to clarify the
    meaning of "reasonable".

A2. No, a value of d that results in a significant loss of precision
    is not reasonable.  An edit is supplied to correct this.

A3. No, it is not reasonable for d to be ridiculously large.
    An edit is supplied to clarify the intent.

A4. No, e should not be bigger than that required to represent the
    largest finite machine-representable number.  An edit is
    supplied to specify this.

A5. Yes, the use of the word "reasonable" in this context is entirely
    meaningless.  An edit is supplied to remove this misleading
    terminology.

EDITS to 10-007r1:

In 10.7.5.2.2, paragraph 2:

[258:9] In 10.7.5.2.2p2 last sentence:
  "Reasonable processor-dependent" -> "Processor-dependent".
{A5.}

[258:10] In 7.5.2.2p2 last sentence, after "value" insert
  ", that do not result in the field being filled with asterisks".
{A1.}

[258:10] Append new sentences to 10.7.5.2.2p2:
  "The value of <d> shall not result in the production of an output
   value that differs from the internal value by more than
   100*SPACING(value), and shall not be more than two larger than the
   maximum number of digits that might be required to distinguish
   between two different machine numbers of the kind of the internal
   value.  The value of <e> shall not be so large that the exponent
   would have a leading zero both when the internal value is the
   largest finite machine number and when it is the smallest finite
   machine number of that kind."
{The first sentence limits the choice of <d> to lose no more than 2
 digits of precision (A2) and to have no more than 2 spurious digits
 of  precision (A3); for some floating-point formats, the upper bound
 is not strong, being d <= 2+MAX(PRECISION(value)+2,RANGE(value)*2).
 The second sentence would allow e==4 for a lop-sided exponent range,
 e.g. -1100 to +900, but would limit e to at most 3 if the exponent
 range is e.g. -308 to +308 (A4).
 Neither of these restrictions prevent a processor from producing
 fewer mantissa or exponent digits for particular values if that does
 not result in serious loss of accuracy.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 10-179    m192  F08/0029 submitted
         10-179r1  m192  Draft answer with straw vote on alternative
         10-179r2  m192  Revised draft - Passed by J3 meeting
         10-202    m192  Passed by J3 letter ballot #21 10-199
         11-006Ar1 m196  Adjust edits to reference 10-007r1
         N1889     m196  Failed WG5 ballot 2 N1877

F08/0029
Corbett NO vote:
I agree that the word "reasonable" should not appear in the
Fortran standard.  The first two proposed edits should be
incorporated.  The third edit should not be adopted.

I object to the third edit on general grounds.  The issues dealt
with in the third edit should be matters of "quality of
implementation."  I see no reason for the Fortran standard to
restrict implementors' choices in this area.

I also object to the third edit on specific grounds.  The
proposed edit makes no provision for nonzero scale factors.  If
a nonzero scale factor is in effect, an implementation might
reasonably choose a value of d that is outside the range
specified by the edit, if only to avoid the scale factor being
outside the allowed range of values.

The phrase
    and shall not be no more than two larger than the
    maximum number of digits that might be required to
    distinguish between       two different machine
    numbers of the kind of the internal value.
should say either "any" between "between" and "two",
or should say "all pairs of" instead of "two."

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

NUMBER: F08/0041
TITLE:  Segment ordering rules
KEYWORDS: segment, allocation
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

(1) Was it intended to allow the allocation of a variable that is not
    a subobject of a coarray to be unordered with respect to its
    definition by another image through a pointer component of a
    coarray?

For example,

  PROGRAM example1
    TYPE t1
      REAL,ALLOCATABLE :: c(:)
    END TYPE
    TYPE t2
      TYPE(t1),POINTER :: p
    END TYPE
    TYPE(t1),TARGET :: x
    TYPE(t2) :: y[*]
    y%p => x                         ! y[n]%p => x[n] for all n.
    SYNC ALL
    IF (THIS_IMAGE()==1) THEN
      ALLOCATE(x%c(1000))            ! Allocates x[1]%c.
    ELSE
      y[1]%p%c(THIS_IMAGE()) = 999   ! Defines some part of x[1]%c.
    END IF
  END PROGRAM

(2) If a variable is already defined (initially or by some segment
    that precedes all other segments in this question), may one image
    reference it while another image causes it to become undefined in
    unordered segments?

For example, is

  PROGRAM example2
    REAL :: x(100)[*]
    x = 1
    SYNC ALL
    IF (THIS_IMAGE()==1) THEN
      PRINT *,SUM(x)
    ELSE
      CALL destroy(x)
    END IF
  CONTAINS
    SUBROUTINE destroy(x)
      REAL,INTENT(OUT) :: x(:)
    END SUBROUTINE
  END PROGRAM

standard-conforming?  This does not appear to violate any of the
segment ordering requirements in 8.5.2 because it is not defined in
any unordered segment (so bullet 1 does not apply), there is no
allocation or pointer association status (so bullet 2 does not apply),
and there is no dummy argument being defined (so bullet 3 does not
apply).

ANSWER:

(1) No, this example violates the requirement of the first bullet in
    paragraph 3 of 8.5.2, which says:
      "if a variable is defined on an image in a segment, it shall not
       be referenced, defined, or become undefined in a segment on
       another image unless the segments are ordered".
    x[1]%c is defined in segment 2 by images 2-N, but is made
    undefined on image 1 (allocation makes a variable undefined except
    when default initialization occurs).

(2) No, this example was not intended to be standard-conforming.  An
    edit is supplied to clarify the intent.

EDITS to 10-007:

[189:14] In 8.5.2 paragraph 3, first bullet point,
  After "if a variable is defined"
  Insert "or becomes undefined"
  (before "on an image in a segment").
{Forbid uncoordinated undefinings of variables.}

SUBMITTED BY: John Reid

HISTORY: 10-201    m193  F08/0041 submitted
         10-201r1  m193  Revised - Passed by J3 meeting
         11-129    m194  Failed J3 letter ballot #22 10-254

** start negative comments
  John Reid's NO vote on F08/0041:

    There are errors in both examples. In example (1), the component of
    type t2 should have type t1. In example (2), the PRINT statement
    should reference x on another image, e.g. PRINT *, x(1)[2].

    More seriously, the edit proposed in 10-201 has been removed. While
    it is not necessary for allocation, it is needed for pointer
    association.  This means that it is desirable to rewrite the
    questions and answers.  Here is my suggestion

    QUESTION:

    (1) If a variable is already defined (initially or by some segment
        that precedes all other segments in this question), may one
        image reference it while another image causes it to become
        undefined in unordered segments?

    For example, is

      PROGRAM example2
        REAL :: x(100)[*]
        x = 1
        SYNC ALL
        IF (THIS_IMAGE()==1) THEN
          PRINT *,x(1)[2]
        ELSE
          CALL destroy(x)
        END IF
      CONTAINS
        SUBROUTINE destroy(x)
          REAL,INTENT(OUT) :: x(:)
        END SUBROUTINE
      END PROGRAM

    standard-conforming?  This does not appear to violate any of the
    segment ordering requirements in 8.5.2 because it is not defined in
    any unordered segment (so bullet 1 does not apply), there is no
    allocation or pointer association status (so bullet 2 does not
    apply), and there is no dummy argument being defined (so bullet 3
    does not apply).

    (2) Was it intended to allow a pointer assignment to a pointer that
        is not a subobject of a coarray to be unordered with respect to
        its definition by another image through a pointer component of
        a coarray?

    For example,

      PROGRAM example1
        TYPE t
          REAL,POINTER :: p
        END TYPE
        REAL,TARGET :: a=0.0, b=1.0
        TYPE(t) :: y[*]
        y%p => a                         ! y[n]%p => a for all n.
        SYNC ALL
        IF (THIS_IMAGE()==1) THEN
          y%p => b                       ! y[1]%p => b
        ELSE
          y[1]%p = 999                   ! Defines a[1] or b[1]?
        END IF
      END PROGRAM

    ANSWER:

    (1) No. This case has been overlooked in the segment ordering rules.
        An edit is supplied to correct this.

    (2) No. This case, too, has been overlooked in the segment ordering
        rules.   An edit is supplied to correct this.

    EDITS to 10-007:

     [189:14] In 8.5.2 paragraph 3, first bullet point,
      After "if a variable is defined"
      Insert "or becomes undefined"
      (before "on an image in a segment").

    [189] In 8.5.2 Segments, paragraph 3, replace the second bullet
          item by
        "if the allocation or the pointer association status of a
         variable is changed on an image in a segment, that variable
         shall not be referenced or defined in a segment on another
         image unless the segments are ordered, and".

  Van Snyder's No vote on F08/0041:

    "is defined" is a static concept.  The requirement should
     always have been "becomes defined".  Therefore the edit should
     be to replace "variable is defined" to "variable becomes
     defined or undefined" -- or do we need another interp to
     repair this?

  Jim Xia's No vote on F08/0041:

    The first example should be fixed to have t2 contains a pointer
    component of type t1.  The second example is perfectly legal.  Seems
    we need to rework on this interp.

  result of ballot on F08/0041:

    In example (1), the component of type t2 is changed to type t1.
    However, more work is needed on this interp as a result of these
    comments => F08/0041 fails.

    The edit in 10-201 referred to above is:
      [189] In 8.5.2 Segments, paragraph 3, replace the second bullet
      item by
        "if the allocation or the pointer association status of a
         variable is changed on an image in a segment, that variable
         shall not be referenced or defined in a segment on another
         image unless the segments are ordered, and"
** end negative comments

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

NUMBER: F08/0045
TITLE:  constraints on entities of type LOCK_TYPE
KEYWORDS: lock, polymorphism
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Consider the following program:

  Program example
    Use Iso_Fortran_Env, Only:lock_type
    type :: m
      class(*), allocatable :: lock
    end type
    type(m) :: om[*]
    allocate(lock_type :: om%lock)
    call inner(om)                  ! Problem call.
  Contains
    Subroutine inner(omm)
      Type(m),Intent(Out) :: omm
      Print *,Allocated(omm%lock)
    End Subroutine
  End Program

Constraint C1304 attempts to prohibit a variable with a LOCK_TYPE
subobject from appearing in a variable definition context, such as the
call to inner, but the dynamic type of om%lock cannot be determined
statically.

Is this program standard-conforming?

ANSWER:

The example was not intended to be standard-conforming.  An ALLOCATE
statement with a <type-spec> should not have been permitted to add
components of type LOCK_TYPE; an edit is supplied to correct this
error.

EDITS to 10-007:

[127:7] In C641,
  After "C_PTR" replace "or" by ",";
  After "C_FUNPTR" insert
    ", LOCK_TYPE (13.8.2.16), or a type with a direct component of
     type LOCK_TYPE that is not a direct component of the declared
     type of any <allocate-object>,".
{Fix condition to prohibit LOCK_TYPE and any type with a LOCK_TYPE
 direct component.  Note that we only want to prohibit "new" lock_type
 components from appearing in the <type-spec>, we don't want to forbid
 ones that are already in the declared type.}

[127:8] After "LOCK_TYPE" delete "(13.8.2.16)".
{Reference now appears one line earlier, so is unnecessary.}

SUBMITTED BY: R. Bader

HISTORY: 10-210    m193  F08/0045 submitted
         10-210r1  m193  Revised - Passed by J3 meeting
         11-129    m194  Failed by J3 letter ballot #22 10-254

** start negative comments
  Jim Xia's No vote on F08/0045:

    The edits makes it illegal to specify LOCK_TYPE as <type-spec> if
    the coarray itself is of LOCK_TYPE.  For example,
      type(lock_type), allocatable :: locks[*]
    The edits make the following allocate statement illegal
      ALLOCATE (LOCK_TYPE: locks[*])

  result of ballot on F08/0045:

    /interp will take this back for more work since we think that Jim
    has a valid complaint => F08/0045 fails

    Perhaps the edit should be changed to

      [127:7] In C641,
        After "C_PTR" replace "or" by ",";
        After "C_FUNPTR" insert
          ", or a type with a direct component of type LOCK_TYPE
           (13.8.2.16) that is not a direct component of the declared
           type of any <allocate-object>,".

      [127:7+] Insert new constraint
        "C641a (R626) If an <allocate-object> is unlimited polymorphic,
               <type-spec> shall not specify the type LOCK_TYPE
               (13.8.2.16)."
** end negative comments

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

NUMBER: F08/0071
TITLE: Vector subscript target
KEYWORDS: Pointer assignment, Vector subscript
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider

  PROGRAM m197006
    REAL,TARGET :: x(100) = [ (i,i=1,100) ]
    REAL,POINTER :: p(:)
    TYPE t
      REAL,POINTER :: q(:)
    END TYPE
    TYPE(t) y
    p => x                     ! (1)
    y = t(x)                   ! (2)
    p => x( [ 1,4,9,25 ] )     ! (3)
    y = t(x( [ 1,4,9,25 ] ))   ! (4)
    PRINT *,y%q
  END PROGRAM

The pointer assignment statement at (1) associates P with X.
The intrinsic assignment statement at (2) includes the effect of
pointer assignment of X to Y%Q, but is not a pointer assignment
statement.

The pointer assignment statement at (3) is not standard-conforming
according to 6.5.3.3.2 paragraph 2:
  "An array section with a vector subscript shall not be
   ... the <data-target> in a pointer assignment statement"

However, the intrinsic assignment statement at (4) is not subject to
this requirement as it is not a pointer assignment statement.

Note that the quoted paragraph is entirely  duplicative, as in:
 - the first bullet item is covered by 12.5.2.4p18,
 - the second bullet item is covered by C724 in 7.2.2.2
   (but C724 does not cover this case either),
 - the third bullet item is covered by C901 in 9.5.1.
Editorial improvements have been made in corrigendum 1.  The entire
paragraph has been rewritten.

Q1. Was the statement marked (4) intended to be allowed?

Q2. If not, was it intended to be prohibited by a constraint like
    C724, or was it intended to be a simple requirement?
    (Editorial note: in any case surely the requirement should appear
    in the pointer assignment subclause.)

ANSWER:

A1. No, this was not intended.  An edit is supplied to correct this.

A2. Constraint C724 was intended to cover this case.  An edit is
    supplied to correct this.

EDIT:

[158:19-20] In 7.2.2.2 Syntax of the pointer assignment statement,
            C724, change ""(R737) A <variable>"
            to "A variable that is a pointer target",
            making the whole constraint read:
  "A variable that is a pointer target shall have either the TARGET
   or POINTER attribute, and shall not be an array section with a
   vector subscript."
{Make the constraint apply to all forms of pointer assignment.}

{Notice that this edit incorporates the list item concerning vector
subscripts from 6.5.3.3.2p2 status quo ante corrigendum 1.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-121    m197  F08/0071 submitted
         12-121r1  m197  Revised wording with same edits - passed
                          by J3 meeting
         12-165r2  m198  Failed J3 letter ballot #25 12-147
         13-250    m200  Revised - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0075
TITLE: Pointer function reference as variable in assignment
KEYWORDS: Pointer function, assignment, defined operator
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

(1) Consider the following

  module Funcs

    interface operator ( .op. )
      module procedure Unary, Binary
    end interface

  contains

    function Unary ( Arg )
      integer, intent(in) :: Arg
      integer, pointer :: Unary
    ...
    end function Unary

    function Binary ( Arg1, Arg2 )
      integer, intent(in) :: Arg1, Arg2
      integer, pointer :: Binary
    ...
    end function Binary

  end module Funcs

  program What

    use Funcs
    integer :: X, Y = 42

    10 .op. x = y

  end program What

Is the "10" in "10 .op. x = y" an operand, and therefore an argument of
a reference to Binary, or is .op. a reference to Unary and "10" a
statement label?

(2) Consider the following

  module Funcs

    interface operator ( .op. )
      module procedure Unary, Binary
    end interface

  contains

    function Unary ( Arg )
      integer, intent(in) :: Arg
      character(len=...), pointer :: Unary
    ...
    end function Unary

    function Binary ( Arg1, Arg2 )
      integer, intent(in) :: Arg1, Arg2
      character(len=...), pointer :: Binary
    ...
    end function Binary

  end module Funcs

  program What

    use Funcs
    integer :: X = 42, Y

    read (10) .op. x, y

  end program What

Is "10" an <io-control-spec-list>, or is "(10) .op. x" a <format>?

Note that this program is valid Fortran 90, and "(10) .op. x" is
a <format> according to the Fortran 90 standard.

ANSWER:

It was an oversight that the programs in (1) and (2) conform to the
syntax and constraints in two different ways.

The problem stems from the over-ambitious extension of allowing
pointer function references to denote variables; this was unambiguous
for <function-reference> syntax, but is not for operator syntax.
Also, operator syntax has other restrictions on it that are intended
to prevent modification of an operand, and these are subverted if the
result is treated as a variable.

Edits are supplied to remove the treatment of pointer-valued operators
as variables.

EDITS:

[117:13] In 6.2, R602, change "<expr>" to "<function-reference>".

[117:15] In 6.2, C602,
         change "<expr> ... has"
         to "<function-reference> shall have".

[158:18+] In 7.2.2.2, R737, add new production
             "<<or>> <expr>".
{Restore description of <data-target> to F2003 version.}

[158:20+] In 7.2.2.2, After C724, add new constraint
  "C724a (R737) An <expr> shall be a reference to a function that has
                a data pointer result."
{Restore F2003 constraint (more or less).}

SUBMITTED BY: Van Snyder

HISTORY: 12-149    m198  F08/0075 submitted
         12-149r1  m198  Revised edit
         12-149r2  m198  Clarified answer, passed J3 meeting
         12-196    m199  Subsumed F08/0076 and Failed J3 letter ballot
                             #26, 12-184
         12-197    m199  Revised answer/edits - passed by J3 meeting
         13-237    m200  Passed by J3 letter ballot #27 13-203
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0076
TITLE: Pointer function reference in READ
KEYWORDS: Pointer function reference, READ, defined operator
DEFECT TYPE: Erratum
STATUS: Subsumed by F08/0075 - No edits in F2008 Corrigendum 3

QUESTION:

Consider the following

  module Funcs

    interface operator ( .op. )
      module procedure Unary, Binary
    end interface

  contains

    function Unary ( Arg )
      integer, intent(in) :: Arg
      character(len=...), pointer :: Unary
    ...
    end function Unary

    function Binary ( Arg1, Arg2 )
      integer, intent(in) :: Arg1, Arg2
      character(len=...), pointer :: Binary
    ...
    end function Binary

  end module Funcs

  program What

    use Funcs
    integer :: X = 42, Y

    read (10) .op. x, y

  end program What

Is "10" an <io-control-spec-list>, or is "(10) .op. x" a <format>?

Note that this program is valid Fortran 90, and "(10) .op. x" is
a <format> according to the Fortran 90 standard.

  An edit is supplied
to remove the ambiguity in the current standard.

ANSWER:

This is another example of the same problem as F08/0075, viz syntactic
ambiguity caused by the F2008 feature "operator syntax for variable
denotation".  Therefore this interpretation request is subsumed by
F08/0075.

EDITS:

See F08/0075.

SUBMITTED BY: Van Snyder

HISTORY: 12-150    m198  F08/0076 submitted
         12-150r1  m198  Revised answer and edits, passed J3 meeting
         12-196    m199  Subsumed by F08/0075, J3 letter ballot #26,
                         12-184

  Result: This is another instance of the same problem (syntactic
          ambiguity) caused by the same feature (operator syntax
          for variable denotation) as F08/0075, so needs to be
          answered together with F08/0075 => example will be added to
          F08/0075, and F08/0076 is therefore subsumed by F08/0075.

         12-197    m199  F08/0075 passed by J3 meeting
         N1990     m202  Passed by WG5 ballot 6, N1987/88/90 -
                          subsumed by F08/0075
         N2002     m203  Subsumed by F08/0075 - no edits in F2008
                          Corrigendum 3

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

NUMBER: F08/0083
TITLE: Type parameter default expressions allow circular dependence
KEYWORDS: type parameter expressions, circular dependence
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider

  type :: T ( I, J )
    integer, kind :: I = J + 1
    integer, kind :: J = I + 1
  end type T

  type(t) :: X(1,2)
  print *, x%i, x%j

  end

1. Is the program standard conforming?

2. What does it print?

ANSWER:

1. The program is not conformant because the standard does not establish
an interpretation.

An edit is supplied to make it clear that the program is not comformant.

2. The standard does not establish an interpretation.

EDITS for 10-007r1:

[152:9] Replace item (9) in the list in 7.1.12p1:

  (9) "a previously declared kind type parameter of the type being
       defined,"

SUBMITTED BY: Van Snyder

HISTORY: 12-172    m199  F08/0083 submitted - passed by J3 meeting
         13-237    m200  Passed by J3 letter ballot #27 13-203
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0084
TITLE: Pointer arguments to PURE functions
KEYWORDS: PURE function, POINTER, INTENT(IN)
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

 Consider the following subprogram:

   Real Pure Function F( X )
     Real,Pointer :: X
     Real :: F
     f = 1.0
     x = 2.0    ! (A)
     Nullify(x) ! (B)
   End Function F

 This subprogram does not conform to Fortran 2003, because both
 statements (A) and (B) violate constraint C1272 which says
   "C1272 In a pure subprogram any designator with a base object that
          ... is a dummy argument of a pure function ... shall not be
          used ... [in] a variable definition context ...".

However, the corresponding constraint in Fortran 2008, C1283, is
missing the condition that applies the constraint to a dummy
argument of a pure function, except when it has INTENT(IN).  Thus
the statements marked (A) and (B) do not violate C1283, and
therefore this subprogram appears to conform to Fortran 2008.

Was this subprogram intended to be standard-conforming?

ANSWER:

No, this subprogram was not intended to be standard-conforming.
An edit is supplied to re-insert the omitted condition.

EDIT to 10-007r1:

[312:31] In 12.7, constraint C1283, after "association",
         insert ", is a dummy argument of a pure function".

SUBMITTED BY: Tobias Burnus

HISTORY: 12-174    m199  F08/0084 submitted
         12-174r1  m199  Revised
         12-174r2  m199  Passed by J3 meeting
         13-237    m200  Passed by J3 letter ballot #27 13-203
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0085
TITLE: Problems with PARAMETERs
KEYWORDS: PARAMETER
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

(1) Consider the program fragment

    Subroutine s
      Parameter (n=1)
      Integer :: x,n       !(A)
      Parameter (x=3)

    The type declaration statement marked "!(A)", declares the
    entities X and N to be of type INTEGER.  Furthermore, as we see by
    the immediately preceding and following PARAMETER statements, both
    X and N are named constants.

    Unfortunately, a constraint says
      C507 (R503) "An <initialization> shall appear if the entity is a
                   named constant (5.3.13)."
    (BTW, R503 is <entity-decl>.)

    Therefore one concludes that the type declaration statement marked
    "!(A)" is not conforming as it violates C507 for both X and N.

    Is this statement intended to be conforming?

(2) Firstly, consider

    Subroutine s2(n)
      Integer,Parameter :: x(n:n+1) = [ 1,2 ]
      Character(n),Parameter :: y = 'abc'
      ...

    The type declaration statements are not conforming because
    according to 5.2.2p1, X and Y are automatic data objects, and C506
    says that <initialization> shall not appear in that case.

    Now consider

    Subroutine s2b(n)
      Implicit Character(n) (a-z)
      Parameter (y = 'abc')
      Integer :: x(n:n+1)
      Parameter(x=[1,2])

    This is not valid Fortran 2003, because 5.2 contains the
    requirement:
      "The combination of attributes that may be specified for a
       particular entity is subject to the same restrictions as for
       type declaration statements regardless of the method of
       specification.  This also applies to PROCEDURE, EXTERNAL, and
       INTRINSIC statements."

    This requirement does not appear in F2008.  However, there is no
    indication in the Introduction of this new feature.

    Is this extension to Fortran 2003 deliberate?

ANSWER:

(1) Yes, the type declaration statement was intended to be allowed.
    An edit is supplied to correct this mistake.

(2) No, the omission of this requirement was inadvertent.  An edit
    is supplied to correct this mistake.

EDITS:

[88:14] In 5.2.1, Replace constraint "C507 (503)" completely with
  "C507 (R501) If the PARAMETER keyword appears, <initialization>
        shall appear in each <entity-decl>."
{Fix Q1.}

[88:14+] In 5.2.1, immediately after constraint C507, insert new
         constraint:
  "C507a An expression that specifies a length type parameter or
         array bound of a named constant shall be a constant
         expression."
{Fix Q2.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-189    m199  F08/0085 submitted
         12-189r1  m199  Passed by J3 meeting
         13-237    m200  Failed as amended by J3 letter ballot
                          #27 13-203
         13-239    m200  Revised - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0086
TITLE:  Implied-shape and separate PARAMETER statement
KEYWORDS: Implied-shape, PARAMETER
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Q1.  Consider

  Program test1
    Character(*) a,b(*)
    Dimension c(*)
    Parameter (a='123', b=['1','2','3'])
    Character(*),Parameter :: c = [ '44','55','66' ]
    Print *,a,b,c
  End

The definition of the assumed-length character named constant A
conforms to Fortran 77 to Fortran 2008.  However, the definition of
the implied-shape named constant B appears not to conform to Fortran
2008, as the standard says in 5.4.11p2
  "A named array constant defined by a PARAMETER statement shall have
   its shape specified in a prior specification statement."
On the other hand, the named constant C does not have such a
requirement, so its definition would appear to be conforming.

This apparent requirement on the named constant B would thus appear to
be inconsistent with those on the named constant C, as well as
inconsistent with the way that assumed length works, and with the
general principle of allowing attributes to be specified either in a
single type declaration statement or with separate specification
statements.

Is the program intended to conform to the Fortran standard?

Q2. Consider

  Subroutine test2(a)
    Real,Dimension(*) :: a,c
    Parameter (c = [ 45.6 ])
    a(:size(c)) = c
  End Subroutine

The <array-spec> in the type declaration statement is ambiguous; if it
is an <implied-shape-spec> then the declaration of A as an
assumed-size array is erroneous, but if it is an <assumed-size-spec>
then the declaration of C as an implied-shape array is erroneous.

Is this program-unit intended to be standard-conforming?

ANSWER:

A1. Yes, the program was intended to conform to the Fortran standard.
    An edit is provided to modify the requirement for prior
    specification so as to allow this case.

A2. Yes, the program is intended to conform to the Fortran standard.
    An edit is provided to add syntax to permit this unambiguously.

EDITS to 10-007r1:

[94:10] 5.3.8.1, R515,
        Change "<implied-shape-spec-list>" to "<implied-shape-spec>".
{This will be the unambiguous implied-shape syntax.}

[94:10+] Insert new production
         "<<or>> <implied-shape-or-assumed-size-spec>".
{This will be the otherwise-ambiguous syntax.}

[95:32] 5.3.8.5p1
  Replace sentence
    "An assumed-size array is declared with an <assumed-size-spec>."
  with
    "A dummy argument is declared to be an assumed-size array by an
     <assumed-size-spec> or an <implied-shape-or-assumed-size-spec>."
{Now two ways of declaring assumed size.}

[95:33-] Insert new BNF term
  "R520a <assumed-implied-spec> <<is>>  [ <lower-bound> : ] *"

[95:33] R521 <assumed-size-spec>, after "<<is>>"
  Replace entire RHS
    "[ <explicit-shape-spec>, ]... [ <lower-bound> : ] *"
  with
    "<explicit-shape-spec-list>, <assumed-implied-spec>"
{The unambiguous case has a list of <explicit-shape-spec>s.}

[95:37+] Insert new BNF rules and constraint
  "R521a <implied-shape-or-assumed-size-spec> <<is>>
                <assumed-implied-spec>

   C534a An object whose array bounds are specified by an
         <implied-shape-or-assumed-size-spec> shall be a dummy data
         object or a named constant."
{The otherwise-ambiguous case.  Note careful wording.}

[96:24-25] 5.3.8.6p1
  Replace sentence
    "An implied-shape array is declared... <implied-shape-spec-list>."
  with
    "A named constant is declared to be an implied-shape array with an
     <array-spec> that is an <implied-shape-or-assumed-size-spec> or
     an <implied-shape-spec>."
{Now two ways of declaring implied shape.}

[96:26] R522,
  Replace right-hand-side (after "<<is>>")
    "[ <lower-bound> : ] *"
  with
    "<assumed-implied-spec>, <assumed-implied-spec-list>".
{This is now the unambiguously implied-shape spec.}

[96:28] p2,
  Change "<implied-shape-spec>s" -> "<assumed-implied-spec>s"
  and    "the <implied-shape-spec-list>" -> "its <array-spec>",
  making the entire paragraph read:
    "The rank of an implied-shape array is the number of
     <assumed-implied-spec>s in its <array-spec>."
{Change rank determination to accord with new syntax term.}

[107:11] 5.4.11p1 "shape" -> "rank".
{In the PARAMETER statement, only require the rank to be specified in
 a prior specification statement.}

NOTE for future investigation:

  The current wording of C533 is slightly defective, as it does not
  clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as
  how that does indeed declare "the array bounds of a dummy data
  object".  C533 should probably be reworded similarly to C534a.

SUBMITTED BY: Bill Long

HISTORY: 12-191    m199  F08/0086 submitted - revised by Malcolm
                          Cohen - passed by J3 meeting
         13-237    m200  Failed letter ballot
         13-235    m200  Revised with straw votes
         13-235r1  m200  Passed by J3 meeting
         13-262    m201  Passed as amended by J3 letter ballot #28
                          13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3
** Revised edits from draft corrigendum ballot - replace entire interp

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

NUMBER: F08/0087
TITLE: Mixed-kind character assignment
KEYWORDS: Mixed kind, character assignment
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

For a processor that supports both ASCII and ISO 10646 UCS-4
character kinds, assuming without loss of generality that
Selected_Char_Kind('ASCII') is equal to 1 and that
Selected_Char_Kind('ISO_10646') is equal to 10646,
consider the following program:

  Module charkinds
    Integer,Parameter :: ascii = 1
    Integer,Parameter :: ucs4 = 10646
  End Module
  Module overload
    Use charkinds
    Interface Assignment(=)
      Module Procedure char_asg
    End Interface
  Contains
    Subroutine char_asg(a,b)
      Character(*,ascii),Intent(Out) :: a
      Character(*,ucs4),Intent(In) :: b
      Do i=1,Min(Len(a),Len(b))
        a(i:i) = Achar(Mod(Iachar(b(i:i))+1,127))
      End Do
      a(i:) = Repeat('*',Len(a)-Len(b))
    End Subroutine
  End Module
  Program test
    Use overload
    Character(10,ascii) x
    x = ucs4_'Hello'
    Print *,'"',x,'"'
  End Program

This program conforms to Fortran 95, which permitted user-defined
assignment between all characters with different kinds.

However, Fortran 2008 provides intrinsic assignment between
ISO 10646 characters and ASCII characters, so user-defined assignment
is not permitted (12.4.3.4.3 and Table 7.8).

Thus there seems to be a contradiction between the Fortran 95
compatibility description in 1.6.3 and 12.4.3.4.3.

Is the program intended to conform to Fortran 2008?
And if it does, does it print
 "Hello     "
(intrinsic assignment)
 "Ifmmp*****"
(user-defined assignment)?

ANSWER:

The program was not intended to conform to the standard.
An edit is provided to remove the contradiction.

EDITS:

[24:14] 1.6.3p1, "Any"
        -> "Except as identified in this subclause, any".
{No longer true.}

[24:15] Split the sentence "The ..." introducing the list into a
        separate paragraph (which will be the third paragraph), and
        insert a new paragraph (as the second paragraph) as follows:
  "Fortran 95 permitted defined assignment between character strings
   of the same rank and different kinds.  This part of ISO/IEC 1539
   does not permit that if both of the different kinds are ASCII,
   ISO 10646, or default kind."
{Describe the incompatibility.}

[25:2+] 1.6.4, after p3, insert a new paragraph.
  "Fortran 90 permitted defined assignment between character strings
   of the same rank and different kinds.  This part of ISO/IEC 1539
   does not permit that if both of the different kinds are ASCII,
   ISO 10646, or default kind."
{Describe the incompatibility.}

SUBMITTED BY: Van Snyder

HISTORY: 13-204    m200  F08/0087 submitted
         13-204r1  m200  Revised - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0088
TITLE: Can ALLOCATE with SOURCE= have side-effects in a PURE proc?
KEYWORDS: Allocate, SOURCE=, PURE, side-effects
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

On comp.lang.fortran Ian Harvey brought up a pointer/PURE
question.

Given a type definition like

 type :: int_ptr
    integer, pointer :: i
 end type int_ptr

And a PURE function like

  PURE function FUN (arg)
    type(int_ptr), intent(in) :: arg
    type(int_ptr), allocatable :: tmp
    FUN = 1
    allocate (tmp, source=arg)
    tmp%i = 2
  end function fun

Is FUN standard conforming?

Doesn't the use of source=arg allow the function to modify a global
entity via the tmp%i = ...?  There don't seem to be any constraints on
what arg%i can point to, which means that the assignment to tmp%i can
have side effects.

Note that C1283(1) prevents usage like
    arg%i = 2

ANSWER:

This was not intended to be standard-conforming.
An edit is supplied to remedy this oversight.

EDITS:

[312:37] In C1283, delete "or" and add a new item
  "(4a) as the <source-expr> in a SOURCE= clause if the designator is
        of a derived type that has an ultimate pointer component, or"

SUBMITTED BY: Dick Hendrickson

HISTORY: 13-226    m200  F08/0088 submitted
         13-226r1  m200  Edits added - passed by J3 meeting
         13-262    m201  Passed J3 leter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0089
TITLE:  Variable-denoting function references change existing
        semantics
KEYWORDS: Pointer function, argument, ASSOCIATE, SELECT TYPE
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Questions 1-3 use this module:

  Module m200c2
    Integer,Target :: x = 42
  Contains
    Function fx()
      Integer,Pointer :: fx
      fx => x
    End Function
  End Module

Q1. Consider this main program

  Program q1
    Use m200c2
    Call test(x,fx())                  ! The call.
  Contains
    Subroutine test(a,b)
      Integer :: a,b
      a = a*10                         ! The assignment.
      Print *,a,b
    End Subroutine
  End Program

According to Fortran 2003, "fx()" in the CALL statement is an
expression and not a variable, and has the value 42.  It follows
that the assignment "a = a*10" is standard-conforming and does
not affect the value of B.  Therefore this program prints
 420 42

However, according to Fortran 2008, "fx()" in the CALL statement is a
variable, and therefore the assignment does not conform to the
standard because it affects the value of B and so violates 12.5.2.13
item (3) which requires all updates to B to go through the dummy
argument, and therefore the behaviour of the program is unspecified.

This conflicts with the statement in clause 1 that all Fortran 2003
programs remain conforming in Fortran 2008.

Is this program intended to remain standard-conforming?

Q2. Consider this main program

  Program q2
    Use m200c2
    Call test(x,fx())                  ! The call.
  Contains
    Subroutine test(a,b)
      Integer,Target :: a,b
      a = a*10                         ! The assignment.
      Print *,a,b
    End Subroutine
  End Program

According to Fortran 2003, "fx()" in the CALL statement is an
expression and not a variable, and has the value 42.  It follows
that the assignment "a = a*10" is standard-conforming and does
not affect the value of B.  Therefore this program prints
 420 42

However, according to Fortran 2008, "fx()" in the CALL statement is a
variable, and therefore the assignment to A affects the value of B, so
the program will print
 420 420

This apparently conflicts with the statement in clause 1 that Fortran
2008 is an upwards compatible extension to Fortran 2003.

Is this program intended to have altered semantics?

Q3. Consider this main program

  Program q3
    Use m200c2
    Associate(y=>fx())   ! The association.
      x = 0              ! The assignment.
      Print *,x,y
    End Associate
  End Program

This main program apparently conforms to both Fortran 2003 and Fortran
2008, but according to Fortran 2003 "fx()" in the association is an
expression, evaluated on entry to the construct, and therefore Y
becomes associated with the value 42, and therefore the program prints
the values (spacing may differ)

 0 42

whereas according to Fortran 2008 "fx()" in the association is a
variable, and every reference to Y is a reference to the associated
variable, so the assignment also changes the value of Y and therefore
the program prints the values

 0 0

This apparently conflicts with the statement in clause 1 that Fortran
2008 is an upwards compatible extension to Fortran 2003.

Is this program intended to have altered semantics?

Q4. Consider this program

  Module m200c2_q4
    Integer,Target :: x = 42
  Contains
    Function fx()
      Class(*),Pointer :: fx
      fx => x
    End Function
  End Module
  Program q4
    Use m200c2_q4
    Select Type (q=>fx())
    Type Is (Integer)
      x = 0
      Print *,x,q
    End Select
  End Program

Using the same logic as Q2, this should print the values
 0 42
in Fortran 2003, but the values
 0 0
in Fortran 2008.

Again, this is not upwards compatible with Fortran 2003.

Is this program intended to have altered semantics.

ANSWER:

A1. This program is not intended to be conforming to Fortran 2008.
    An edit is supplied to note the incompatibility between Fortran
    2008 and previous Fortran standards.

A2. This program was intended to have different semantics in Fortran
    2008.  An edit is supplied to note the incompatibility.

A3. This program was intended to have different semantics in Fortran
    2008.  An edit is supplied to note the incompatibility.

A4. This program was intended to have different semantics in Fortran
    2008.  An edit is supplied to note the incompatibility.

EDITS to 10-007r1:

[24:11+] 1.6.2 "Fortran 2003 compatibility",
  insert new paragraphs at the end of the subclause,
  after the paragraphs added by Corrigendum 2:

  "An actual argument that corresponds to a nonpointer dummy argument
   and which is a <function-reference> to a pointer function is
   regarded as a variable by this part of ISO/IEC 1539 but was
   regarded as an expression by Fortran 2003; if the target of the
   pointer result is modified other than through that dummy argument
   during execution of the called procedure, and that dummy argument
   does not have the POINTER or TARGET attribute, the program does not
   conform to this part of ISO/IEC 1539.  If that dummy argument does
   have the POINTER or TARGET attribute, any further reference to that
   dummy argument will have the modified value according to this part
   of ISO/IEC 1539 instead of the initial value as specified by
   ISO/IEC 1539-1:2004.

   A <selector> for an ASSOCIATE or SELECT TYPE construct that is a
   <function-reference> to a pointer function is regarded as a
   variable by this part of ISO/IEC 1539; if the target of the pointer
   result is modified during execution of the construct, any further
   references to the <associate-name> will have the modified value
   according to this part of ISO/IEC 1539 instead of the initial value
   as specified by ISO/IEC 1539-1:2004."

[24:14-16] 1.6.3 "Fortran 95 compatibility", paragraph 1, sentence 2,
  Change "Any" to "Except as identified in this subclause, any",
  Delete "The following Fortran 95 features .. 1539."
{We are about to add a non-conformance, so the last sentence will
 become wrong and it is in any case unnecessary.}

[24:17-27] Change all bullet points into separate paragraphs.
{These are no longer a list.}

[24:27+] Insert new paragraph at end of subclause
  "An actual argument that corresponds to a nonpointer dummy argument
   and which is a <function-reference> to a pointer function is
   regarded as a variable by this part of ISO/IEC 1539 but was
   regarded as an expression by Fortran 95; if the target of the
   pointer result is modified other than through that dummy argument
   during execution of the called procedure, the program does not
   conform to this part of ISO/IEC 1539."

[24:30] 1.6.4 "Fortran 90 compatibility", paragraph 1
  Change "Any" to "Except as identified in this subclause, any",

[25:6+] Insert new paragraph at end of subclause.
  "An actual argument that corresponds to a nonpointer dummy argument
   and which is a <function-reference> to a pointer function is
   regarded as a variable by this part of ISO/IEC 1539 but was
   regarded as an expression by Fortran 95; if the target of the
   pointer result is modified other than through that dummy argument
   during execution of the called procedure, the program does not
   conform to this part of ISO/IEC 1539."

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-228    m200  F08/0089 submitted
         13-228r1  m200  Revised - passed by J3 meeting
         13-262    m201  Passed as amended by J3 letter ballot #28
                          13-255r1
         N1990     m202  Failed WG5 ballot N1988/n1987

-----------------------
From N1990: F08/0089

Corbett reason for NO vote

Questions Q1 and Q2 assume that if a pointer actual argument
has the form of an expression and the corresponding dummy
argument is a nonpointer dummy argument without the VALUE
attribute, the dummy argument becomes argument associated
with the value of the target of the value of the pointer
actual argument.  On the newsgroup comp.lang.fortran, Ian
Harvey pointed out that the Fortran standards do not support
that premise.  Paragraph 2 of Clause 12.5.2.3 of the
Fortran 2008 standard states

     If a nonpointer dummy argument without the VALUE
     attribute corresponds to a pointer actual argument
     that is pointer associated with a target, the
     dummy argument becomes argument associated with
     that target.

Paragraph 8 of Clause 12.4.1.2 of the Fortran 2003 standard
states

     Except in references to intrinsic inquiry functions,
     if the dummy argument is not a pointer and the
     corresponding actual argument is a pointer, the
     actual argument shall be associated with a target
     and the dummy argument becomes argument associated
     with that target.

Paragraph 6 of Clause 12.4.1.1 of the Fortran 95 standard
states

     If the dummy argument is not a pointer and the
     corresponding actual argument is a pointer, the
     actual argument shall be currently associated
     with a target and the dummy argument becomes
     argument associated with that target

The paragraph added between paragraphs 3 and 4 of
Clause 12.4.1.1 of the Fortran 90 standard by
Corrigendum 2 states

     If the dummy argument is not a pointer and the
     corresponding actual argument is, the actual
     argument must be currently associated with a
     target and the dummy argument becomes argument
     associated with that target.

That text was added as a result of interpretation
F90/000039.

In the examples given in questions Q1 and Q2, the
actual argument fx() is a pointer actual argument
corresponding to a nonpointer dummy argument.
Therefore, the dummy argument becomes argument
associated with the target of the pointer actual
argument, which is the module variable x.  The dummy
argument does not become argument associated with the
value of the target of the pointer.  Thus, there is
no semantic difference between Fortran 2008 and the
previous standards in this regard.

The answers and edits given for questions Q1 and Q2 are
based on the same premise as the questions themselves
and should be rejected.

I asked people to compile and run the example programs
given in questions Q1 and Q2 and variations of them
using a variety of compilers.  In most, but not all,
cases, the results were consistent with the semantics
stated in the Fortran standards, not with the semantics
assumed by questions Q1 and Q2.

Questions Q3 and Q4 are consistent with the standards,
as are the corresponding answers and edits, but I do not
care for the nature of the changes that will result if
interpretation F08/0075 is passed.  I think changing the
language so that the form of a function reference
determines its meaning is a mistake.

Long comment:

Twice in the edits appears "...a <function-reference> to a
pointer function is regarded as a variable...". Should this
be a "data pointer function"?

Snyder comment:

The term "pointer function" is not used as a noun,
although "nonpointer function" is so used at [454:36].
I have a slight preference that "pointer function" in
the edit for [24:11+] be replaced by "function that
returns a pointer result" in both paragraphs.  The
same change ought to be made in the edits for [24:27+]
and [25:6+]

A parallel change ought to be made at [454:36], but
that can be done editorially rather than within this
interpretration.

Decision of /INTERP: Failed.

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

NUMBER: F08/0090
TITLE: What restrictions apply to initialization and PARAMETER?
KEYWORDS: PARAMETER, initialization, conformable, type conversion
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider the programs

  Program m200c3_1
    Integer :: a(10,10)
    Parameter (a = [ (i,i=1,100) ] )
    Print *,a
  End Program

  Program m200c3_2
    Parameter (b = 'ok')
    Print *,b
  End Program

  Program m200c3_3
    Integer :: x(23) = [ 1 ]
    Print *,x
  End Program

  Program m200c3_4
    Integer :: y = 'ok'
    Print *,y
  End Program

The PARAMETER statement for the named constant A has an expression
whose shape does not conform with that of A.  The PARAMETER statement
for the named constant B has an expression whose type does not conform
to that of B.  The <initialization> for X is not conformable in shape.
The <initialization> for Y is not conformable in type.

There appears to be no requirement either for shape or type
conformance, in Fortran 2008 or in previous Fortran standards, except
for initializing data pointers.

Q1. Do any of these programs conform to Fortran 2008?

Q2. If there is meant to be a requirement for the shapes to conform or
    for the types to be convertible, should this not be a constraint?

ANSWER:

A1. No, these programs do not conform to Fortran 2008, as no
    interpretation is established for any of them.  Edits are
    provided to clarify this.

A2. This is not a constraint.  A future revision of Fortran might
    choose to mandate diagnosis of these errors.

EDIT to 10-007r1:

[88:30+] 5.2.1 Syntax, Insert new paragraph at end of subclause
  "If <initialization> appears for a nonpointer entity,
   - its type and type parameters shall conform as specified for
     intrinsic assignment (7.2.1.2);
   - if the entity has implied shape, the rank of <initialization>
     shall be the same as the rank of the entity;
   - if the entity does not have implied shape, <initialization> shall
     either be scalar or have the same shape as the entity.".

[107:12+] 5.4.11 PARAMETER statement, after p2, Insert new paragraph
  "The constant expression that corresponds to a named constant shall
   have type and type parameters that conform with the named constant
   as specified for intrinsic assignment (7.2.1.2).  If the named
   constant has implied shape, the expression shall have the same rank
   as the named constant; otherwise, the expression shall either be
   scalar or have the same rank as the named constant.".

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-229    m200  F08/0090 submitted - passed by J3 meeting
         13-262    m201  Passed J3 letter ballot #28 13-255r1
         N1990     m202  Passed by WG5 ballot 6 N1987/88/90
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0091
TITLE: Derived type with no components
KEYWORD: Derived type
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Q1. Consider

  Program m7_1
  Type empty
  End Type
  Type(empty),Target :: x
  Type(empty),Pointer :: y
  y => x
  Print *,Associated(y,x)
  End

Is this program standard-conforming, and does it print T or F?

According to 16.5.3.2p2,
  item 1  is default integer etc, N/A
  item 2 is double precision etc, N/A
  item 3 is default character, N/A
  item 4 is C character, N/A
  item 5 is SEQUENCE type, N/A

According to item (6),
  "a nonpointer scalar object of any type not specified in items
   (1)-(5) occupies a single unspecified storage unit that is
   different [from everything else]"

If that analysis is correct, X occupies a single unspecified storage
unit, not zero storage units, and therefore T should be printed.

Q2. Consider

  Program m7_2
  Type sempty
    Sequence
  End Type
  Type(sempty),Target :: x
  Type(sempty),Pointer :: y
  y => x
  Print *,Associated(y,x)
  End

Is this program standard-conforming, and does it print T or F?

Now X falls into item 5, which makes it a "sequence of storage
sequences corresponding to the sequence of its ultimate components";
there are no ultimate components, this makes it a zero-sized storage
sequence and therefore F should be printed.

This does not seem to be consistent with the apparent answer to Q1.

Q3. Consider

  Program m7_3
  Type numeric_empty
    Sequence
  End Type
  Type character_empty
    Sequence
  End Type
  Type(numeric_empty) a
  Integer b
  Character c
  Type(character_empty) d
  Equivalence(a,b)             ! E1.
  Equivalence(c,d)             ! E2.
  End

Is this program conforming?

According to the definitions in 4.5.2.3, NUMERIC_EMPTY is a numeric
sequence type and therefore one might expect to be able to EQUIVALENCE
it to an INTEGER.  Similarly, CHARACTER_EMPTY is a character sequence
type and therefore one might expect to be able to EQUIVALENCE it to a
CHARACTER.

However, NUMERIC_EMPTY is clearly also a character sequence type, and
therefore statement E1 violates C592 because B is not character or
character sequence.

Similarly, CHARACTER_EMPTY is clearly also a numeric sequence type,
and therefore statement E2 violates C591.

It seems very strange to have a type that is simultaneously numeric
and character sequence type.

Q4. Consider

  Program m7_4
  Type numeric_empty_2
    Sequence
    Real c(0)
  End Type
  Type character_empty_2
    Sequence
    Character(0) c
  End Type
  Type(numeric_empty_2) a
  Integer b
  Character c
  Type(character_empty_2) d
  Equivalence(a,b)             ! E3.
  Equivalence(c,d)             ! E4.
  End

Does this program conform?

According to the definitions in 4.5.2.3, NUMERIC_EMPTY_2 is a numeric
sequence type and not a character sequence type, and conversely
CHARACTER_EMPTY_2 is a character sequence type and not a numeric
sequence type, and therefore the constraints for the statements at E3
and E4 are not violated.

Thus this appears to be conforming, in contradiction to the example in
Q3, even though the storage sequence of NUMERIC_EMPTY,
NUMERIC_EMPTY_2, CHARACTER_EMPTY, and CHARACTER_EMPTY_2 are all the
same.

This does not look very consistent with the situation in Q3.

ANSWER:

A1.  The program is conforming and prints T.

A2.  The program was not intended to conform; SEQUENCE makes no sense
     when there are no components.  An edit is needed to correct this.

A3.  The program does not conform as a sequence type must have at
     least one component.

A4.  The program is conforming.  The apparent design inconsistency is
     not an error in the standard.

EDIT to 10-007r1:

[62:19] 4.5.2.3, in constraint C436
        After "appears," insert "the type shall have at least one
               component,".

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-266    m201  F08/0091 submitted
         13-266r1  m201  Revised - passed by J3 meeting
         13-313    m202  Passed as amended by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0092
TITLE: Derived type parameter requirements
KEYWORD: Derived type parameter
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider

  Type t1(a,a)
    Integer,Kind :: a
    Integer,Len :: a
  End Type
  Type t2(a)
    Integer,Kind :: a,a,a
  End Type

These type definition appears to valid, in that
(a) there is no requirement that a type parameter appears only once in
    the <type-param-name-list>;
(b) there is no requirement that a type parameter appears in only one
    <type-param-def-stmt>, and only once.

Were these intended to be valid?  What is their meaning?

ANSWER:

These were not intended to be valid, and they are not valid because
the standard does not establish an interpretation for them.  Unique
names for type parameters can possibly be deduced from the scoping
rules.

Edits are supplied to make the requirements explicit.

EDITS to 10-007r1:

[61:19+] In 4.5.2.1, after C427 insert new constraint
  "C427a (R426) The same <type-param-name> shall not appear more than
         once in a <derived-type-stmt>."
{Require unique names for type parameters.}

[64:8] In 4.5.3.1, C438, after "shall appear" insert "exactly once".
{Forbid multiple declarations of a type parameter, whether in the same
 <type-param-def-stmt> or more than one.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-267    m201  F08/0092 submitted - passed by J3 meeting
         13-313    m202  Passed as amended by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0093
TITLE: Process exit status and error termination
KEYWORD: ERROR STOP
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Many operating systems today (e.g. Posix-related ones) use a process
exit status of zero to indicate successful execution, whereas nonzero
indicates an error.  (Occasionally nonzero values, e.g. 1, also
indicate success.)

Fortran STOP and ERROR STOP with an integer <stop-code> are
recommended to use the <stop-code> as the exit status.  The STOP
statement without an integer <stop-code> is recommended to have an
exit status of zero; this conforms to common practice since STOP
initiates normal termination.

The standard is silent on the effect of error termination, except in
the case of an ERROR STOP (sans integer <stop-code>) which is
unexpectedly recommended to also return an exit status of zero.

Q1. Is this intentional?  Should the exit code for ERROR STOP not have
    been recommended to be nonzero?

Q2. Should the recommendation for an ERROR STOP not also apply to
    error termination by other causes?

ANSWER:

A1. It was not intended to recommend returning "success" for error
    termination.  An edit is supplied to correct this.

A2. Yes, the recommendation for an ERROR STOP without an integer
    <stop-code> should also apply to other means of standard-defined
    error termination.  An edit is supplied to correct this omission.

EDIT to 10-007r1:

[33:36+] 2.3.5, before Note 2.7, insert new note
  "NOTE 2.6a
   If the processor supports the concept of a process exit status, it
   is recommended that error termination initiated other than by an
   ERROR STOP statement supplies a processor-dependent nonzero value
   as the process exit status."
{Recommendation for error termination other than by ERROR STOP.}

[188:10+10] In 8.4, Note 8.30,
            Before "is of type character or does not appear"
            Insert "in a STOP statement".
{Limit zero recommendation to STOP, not ERROR STOP.}

[188:10+11+] At the end of Note 8.30, insert a new paragraph
  "If the <stop-code> in an ERROR STOP statement is of type character
   or does not appear, it is recommended that a processor-dependent
   nonzero value be supplied as the process exit status, if the
   processor supports that concept."
{Specify nonzero exit for ERROR STOP.}

[459:17+] After the bullet item "how soon an image terminates if
  another image initiates error termination (2.3.5);"
  Insert new bullet point
  "the recommended process exit status when error termination is
   initiated other than by an ERROR STOP statement with an integer
   <stop-code> (2.3.5);"
{Probably unnecessary, seeing how it is only a recommendation, but
 maybe a good idea anyway.}

SUBMITTED BY: Bill Long/Malcolm Cohen

HISTORY: 13-268    m201  F08/0093 submitted - passed by J3 meeting
         13-313    m202  Passed as amended by J3 letter ballot 13-297
         N1994     m202  Passed as amended by WG5 ballot 7 N1991/92/94
** [460:24+] moved to [459:17+]
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0094
TITLE: Procedure statement and double colon
KEYWORD: PROCEDURE, Interface block
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Fortran 2003 did not permit a double colon in the <procedure-stmt> in
an interface block.  Fortran 2008 syntax seems to allow this, but it
is not mentioned in the Introduction as a new F2008 feature.

Is this apparent new feature deliberate?

ANSWER:

Yes, this new feature was intended.

An edit is provided to add mention of it to the Introduction.

EDIT:

[xvi] Introduction, p2, "Programs and procedures:" bullet,
      After "empty CONTAINS section is allowed."
      Insert "A PROCEDURE statement can have a double colon before
              the first procedure name."

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-274    m201  F08/0094 submitted - passed by J3 meeting
         13-313    m202  Passed by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0095
TITLE: Is PRESENT allowed in specification and constant expressions
KEYWORD: PRESENT, optional dummy argument
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Q1. Consider

  Subroutine s1(a)
    Integer,Optional :: a
    Logical,Parameter :: x = Present(a)
    Print *,x
  End Subroutine

Does this program unit conform to the standard?
7.1.12 item (4) permits
  "a specification inquiry where each designator or function argument
   is ...
     (b) a variable whose properties inquired about are not
        (i) assumed,
        (ii) deferred, or
        (iii) defined by an expression that is not a constant
              expression,"
PRESENT is a specification inquiry (because it is an intrinsic inquiry
function), and the standard does not say that the "presence" of an
optional dummy argument is an assumed or deferred attribute, and it
does not appear to be "defined by an expression" either.

On the other hand, the standard does not say anything about what kind
of property the presence is.

Q2. Consider

  Subroutine s2(a)
    Integer,Optional :: a
    Real x(Merge(2,3,Present(a)))
    If (Present(a)) Then
      x = [ 1,2,a ]
    Else
      x = [ 1,2 ]
    End If
    Print *,x
  End Subroutine

Does this program unit conform to the standard?  It appears to satisfy
the rules for specification expression, similarly to how it satisfies
the rules for a constant expression, but then the standard is silent
as to what sort of property "presence" is...

Q3. Consider

  Subroutine s3(a)
    Character(*),Optional :: a
    Real x(Len(a))
    Print *,Size(x)
  End Subroutine

Does this program unit conform to the standard?  Using the same
reasoning as Q1 and Q2, it appears to conform, but if A is absent,
LEN(A) is not permitted by 12.5.2.12.

ANSWER:

A1. Program unit S1 was not intended to conform to the standard.
    An edit is provided to clarify that this is not valid.

A2. Program unit S2 was intended to conform to the standard.
    An edit is provided to clarify that this is valid.

A3. Program unit S3 was not intended to conform to the standard.
    An edit is provided to clarify that this is not valid.

EDITS to 10-007r1:

[150:24] 7.1.11p2, item (9)(b)
  after "variable" insert ",that is not an optional dummy argument, ".
{Prevent specification enquiries on optional dummy arguments.}

[150:27+] 7.1.11p2, after item (9) entirely,
  insert "(9a) a specification inquiry that is a constant expression,
          (9b) a reference to the intrinsic function PRESENT,"
{Allow inquiries on optional dummy arguments that will not violate the
 rules in 12.5.2.12 when the dummy is absent,
 and allow PRESENT to be used.}

[150:37] 7.1.11p4, item (1)
  after "intrinsic inquiry function" insert "other than PRESENT".
{Remove PRESENT from list of specification inquiries, this fixes
 constant expressions.}

SUBMITTED BY: Malcolm Cohen/Van Snyder

HISTORY: 13-278    m201  F08/0095 submitted
         13-278r1  m201  Passed by J3 meeting
         13-313    m202  Passed by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0096
TITLE: Is VALUE permitted for an array in a BIND(C) procedure?
KEYWORD: array, BIND(C), VALUE
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider

  INTERFACE
    SUBROUTINE s(a) BIND(C)
      USE ISO_C_BINDING
      REAL(C_float),VALUE :: a(100)
    END
  END INTERFACE

Q1. Does this interface conform to the Fortran standard?

Q2. If so, what prototype does it interoperate with?

ANSWER:

A1. C does not have arrays that are passed by value, so this was not
    intended to conform to the Fortran standard.  An edit is provided
    to clarify this.

A2. This question is moot.

EDITS to 10-007r1:

[306:31] 12.6.2.2, C1255, after "(15.3.5, 15.3.6)" insert
  "that is not an array with the VALUE attribute,"
{Do not permit BIND(C) to have arrays by value.}
{Note: TS 29113 replaces this same constraint.}

[433:12] 15.3.7p2, item (4), after "any" insert "scalar".
{Do not describe arrays by value in a prototype.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-284    m201  F08/0096 submitted - passed by J3 meeting
         13-313    m202  Passed as amended by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0097
TITLE: Is the optional comma allowed in TYPE(CHARACTER*...)?
KEYWORD: TYPE, CHARACTER
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider

  CHARACTER*1, A
  TYPE(CHARACTER*1,) B

The optional comma in the declaration of B looks ugly.
Is this deliberate?

ANSWER:

No, this syntax was inadvertently allowed.  An edit is provided to
remove it.

EDITS to 10-007r1:

[51:26+] 4.3.1.1, after C406, insert new constraint
  "C406a (R403) In TYPE(<intrinsic-type-spec>) the
         <intrinsic-type-spec> shall not end with a comma."

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-285    m201  F08/0097 submitted - passed by J3 meeting
         13-313    m202  Passed by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0098
TITLE: How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt?
KEYWORD: LOCK
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 3

QUESTION:

Consider

  LOCK ( x, ACQUIRED_LOCK=n1, ACQUIRED_LOCK=n2, STAT=n3, STAT=n4 )

Is this conforming?

Multiple STAT= are prohibited from a <sync-stat-list>, but this is a
<lock-stat-list> so that does not apply.  There is no constraint
anywhere about how many ACQUIRED_LOCK= specifiers may appear.

ANSWER:

No, this was not intended to be conforming.  No specifier was intended
to be allowed to appear more than once.

EDITS to 10-007r1:

[194:2+] 8.5.6, after R864, insert new constraint
  "C852a No specifier shall appear more than once in a given
         <lock-stat-list>."

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-286    m201  F08/0098 submitted - passed by J3 meeting
         13-313    m202  Passed by J3 letter ballot 13-297
         N1994     m202  Passed by WG5 ballot 7 N1991/92/94
         N2002     m203  In F2008 Corrigendum 3

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

NUMBER: F08/0099
TITLE: VOLATILE in specification expressions
KEYWORD: VOLATILE, specification expression
DEFECT TYPE: Interpretation.
STATUS: Passed by WG5 ballot

QUESTION:

Is the following subprogram required always to print "T T"?

  subroutine Wobbly ( N )
    integer, volatile :: N
    integer :: A ( n, n )
    integer :: B ( n * n )
    print *, size(a) == size(b), size(a,1) == size(a,2)
  end subroutine Wobbly

ANSWER:

No.

There are three specification expressions in the subroutine, and the
volatile variable N appears in each of them.  Since, being volatile,
the variable N might have a different value each time it is
referenced, these three specification expressions might receive
different values for their references to N.  If that happens, the
array sizes might well be different.

EDITS:

None.

SUBMITTED BY: Van Snyder

HISTORY: 13-298r1  m202  F08/0099 submitted
         13-298r2  m202  Revised answer - passed by J3 meeting
         14-192    m204  Passed by J3 letter ballot 14-146
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0100
TITLE: IMPORT statement and prior explicit declaration
KEYWORD: IMPORT statement, prior explicit declaration
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Q1. Does the following program fragment conform to the 2008 standard?

  subroutine S ( P )
    interface
      subroutine Q ( X )
        real, intent(inout) :: X
      end subroutine Q
    end interface
    interface
      subroutine P ( A )
        import
        procedure (R) :: A
      end subroutine P
    end interface
    procedure (Q) :: R
  end subroutine S

12.4.3.3p2 says "If an entity that is made accessible by this means is
accessed by host association and is defined in the host scoping unit, it
shall be explicitly declared prior to the interface body."

However, although the procedure R is declared in the host scoping unit
it is not defined in the host scoping unit, so this is ineffective.

Q2. If the IMPORT statement were changed to "IMPORT R", would that be
    conforming?

12.4.3.3p1 says
  "An entity that is imported in this manner and is defined in the
   host scoping unit shall be explicitly declared prior to the
   interface body."

Again, procedure R is declared but not defined in the host scoping
unit, so this requirement is ineffective.

ANSWER:

These examples were not intended to conform to the Fortran standard.
An edit is provided.

EDITS:

[282:7] 12.4.3.3p1, after "imported in this manner and is"
        change "defined" to "declared".

[282:14] p2, after "is accessed by host association and is"
         change "defined" to "declared".

SUBMITTED BY: Van Snyder

HISTORY: 13-305    m202  F08/0100 submitted
         13-305r1  m202  Revised answer & edits - passed by J3 meeting
         14-192    m204  Passed by J3 letter ballot 14-146
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0101
TITLE: NAMELIST and multiple occurrences of a variable
KEYWORD: NAMELIST
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider

  Program p1
    Real :: x = 3, y = 4
    Namelist /n/ x, y
    Write (*,n)
  End Program

According to 5.6,
  "The order in which the variables are specified in the NAMELIST
   statement determines the order in which the values appear on
   output."

However, this stops short of saying that the order is the same, merely
that it determines it.  Perhaps it might be standard-conforming for a
processor to always produce the values in reverse order, for example.
10.11.4 does not seem to address the issue of what the order is.

Q1: Is the order meant to be the same?

Consider

  Program p2
    Real :: x = 3, y = 4
    Namelist /n/ x, y, x
    Write (*,n)
  End Program

This program did not conform to Fortran 90, but does conform to
Fortran 2003 and later.  The Fortran 2008 standard says (5.6p2):

  "The order in which the variables are specified in the NAMELIST
   statement determines the order in which the values appear on
   output."

However, there are only two variables in the NAMELIST statement, X
and Y.  Therefore it seems to be ambiguous whether the output should
be something like
  &N X=3 Y=4 /
or
  &N Y=4 X=3 /

Some compilers produce
  &N X=3 Y=4 X=3 /
but this is not an ordering of the variables X and Y.

Q2. Is this program intended to conform to the standard, and if so,
    what is the intended output?

ANSWER:

A1. Yes, the order is meant to be the same.  An edit is supplied to
    clarify this.

A2. The program was intended to conform to the standard, and the output
    was intended to be the third option.  An edit is supplied to
    correct the text in 5.6.

EDIT:

[111:13-14] 5.6p2, replace entire paragraph with
  "The order in which the values appear on output is the same as the
   order of the <namelist-group-object>s in the namelist group object
   list; if a variable appears more than once as a
   <namelist-group-object> for the same namelist group, its value
   appears once for each occurrence".

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-314    m202  F08/0101 submitted, first option selected by
                          straw vote - passed by J3 meeting
         14-192    m204  Passed by J3 letter ballot 14-146
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0102
TITLE: MERGE and polymorphism
KEYWORD: MERGE, polymorphic
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider

  Program test
    Type t
    End Type
    Type,Extends(t) :: t2
    End Type
    Class(t),Allocatable :: x,y
    Type(t),Allocatable :: a
    x = t()
    y = t2()
    a = t()
    Do i=1,2
      Select Type (z=>Merge(a,x,i==1))   ! A
      Type Is (t)
        Print *,'ok'
      Type Is (t2)
        Print *,'FAIL'
      End Select
    End Do
    Do i=1,2
      Select Type (z=>Merge(x,a,i==1))   ! B
      Type Is (t)
        Print *,'ok'
      Type Is (t2)
        Print *,'FAIL'
      End Select
    End Do
    Do i=1,2
      Select Type (z=>Merge(a,y,i==1))   ! C
      Type Is (t)
        Print *,'t'
      Type Is (t2)
        Print *,'t2'
      End Select
    End Do
    Do i=1,2
      Select Type (z=>Merge(y,a,i==1))   ! D
      Type Is (t)
        Print *,'t'
      Type Is (t2)
        Print *,'t2'
      End Select
    End Do
    Do i=1,2
      Select Type (z=>Merge(x,y,i==1))   ! E
      Type Is (t)
        Print *,'t'
      Type Is (t2)
        Print *,'t2'
      End Select
    End Do
  End Program

According to the standard, the type of the result of MERGE is the same
as the type of TSOURCE.  One might imagine that this means that the
result is polymorphic if and only if TSOURCE is polymorphic.  This
would be a slightly unusual and unexpected asymmetry.

Also, the types of FSOURCE and TSOURCE have to be the same.  If this
means both the declared and dynamic types, one might imagine that this
means that the result is polymorphic if and only if both FSOURCE and
TSOURCE are polymorphic, since otherwise the non-polymorphic argument
decides the type.

On the other hand, if the type requirements are talking about the
declared type only, one might imagine that the result is polymorphic
if either TSOURCE or FSOURCE is polymorphic.

However, in any case there would seem to be an error in the standard,
since the result is specified to be the same as TSOURCE, rather than
the same as whichever argument is chosen to be the result value; if
this refers to the dynamic type, it is contradictory when FSOURCE is
chosen as the result value.  And if it does not refer to the dynamic
type, there appears to be no statement which says what the dynamic
type of the result is.

Q1.  Is the apparent asymmetry between the treatment of TSOURCE and
     FSOURCE intended?

Q2.  Which of the MERGE invocations A-E are polymorphic?

Q3.  When the result of MERGE is polymorphic, are the dynamic types of
     TSOURCE and FSOURCE permitted to be different?  And if they are,
     is the dynamic type of the result the same as the chosen argument
     and not necessarily the same as TSOURCE?

ANSWER:

A1. There is no asymmetry between TSOURCE and FSOURCE, because they
    are required to have the same type and type parameters.  This
    means that both the declared and dynamic types and type parameters
    must be the same.

A2. Only MERGE invocation E is polymorphic.  An edit is provided to
    clarify this.

A3. No, the dynamic types and type parameters are required to be the
    same.

Note that because MERGE is elemental, it needs the type and type
parameters to be the same for both the declared and dynamic types,
otherwise the principle that all elements of an array have the same
(declared and dynamic) type and type parameters would be broken.

EDITS:

[368:26] 13.7.110p4 (Result Characteristics),
         "Same as TSOURCE." ->
         "Same type and type parameters as TSOURCE.  Because TSOURCE
          and FSOURCE are required to have the same type and type
          parameters (for both the declared and dynamic types), the
          result is polymorphic if and only if both TSOURCE and
          FSOURCE are polymorphic."

SUBMITTED BY: Malcolm Cohen

HISTORY: 13-321    m202  F08/0102 submitted
         13-321r1  m202  Revised example - passed by J3 meeting
         14-192    m204  Passed by J3 letter ballot 14-146
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0103
TITLE: Pointers to internal procedures with different host instances
KEYWORD: internal procedure, procedure pointer, host instance
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider:

    MODULE TYPES
      ABSTRACT INTERFACE
        SUBROUTINE SUBROUTINE()
        END SUBROUTINE SUBROUTINE
      END INTERFACE
      TYPE PPS
        PROCEDURE(SUBROUTINE), POINTER, NOPASS :: SU_PTR
      END TYPE PPS
    END MODULE TYPES

    SUBROUTINE CPPS(PPA)
      USE TYPES
      TYPE(PPS), DIMENSION(:) :: PPA
      INTEGER I, J, N
      N = SIZE(PPA)
      DO I = 1, N
        CALL PPA(I)%SU_PTR()
      END DO
      PRINT *,((ASSOCIATED(PPA(I)%SU_PTR,PPA(J)%SU_PTR),I=1,N),J=1,N)
    END SUBROUTINE CPPS

    RECURSIVE SUBROUTINE OUTER(PPA)
      USE TYPES
      TYPE(PPS), DIMENSION(:) :: PPA
      INTERFACE
        SUBROUTINE CPPS(PPA)
          USE TYPES
          TYPE(PPS), DIMENSION(:) :: PPA
        END SUBROUTINE CPPS
      END INTERFACE
      IF (SIZE(PPA) .EQ. 3) THEN
        CALL CPPS(PPA)
      ELSE
        CALL OUTER( (/ PPA, PPS(INNER) /) )
      END IF
    CONTAINS
      SUBROUTINE INNER()
        WRITE (*,*) 'SIZE(PPA) =', SIZE(PPA)
      END SUBROUTINE INNER
    END SUBROUTINE OUTER

    PROGRAM MAIN
      USE TYPES
      INTERFACE
        RECURSIVE SUBROUTINE OUTER(PPA)
          USE TYPES
          TYPE(PPS), DIMENSION(:) :: PPA
        END SUBROUTINE OUTER
      END INTERFACE
      TYPE(PPS),DIMENSION(0) :: PPA
      CALL OUTER(PPA)
    END PROGRAM MAIN

Does this program print all true values?

The procedure pointers are all associated with the internal procedure
INNER, which might lead one to believe that the answer is yes (that
is, they are all associated with the same target), but each procedure
pointer at each nesting level has a different host instance, which
might lead one to believe that the answer is no (and that therefore
only one of each of the 3-element sequences printed will be T).

ANSWER:

No, the program does not print all true values; two procedure pointers
to the "same" internal procedure are only associated if the host
instances are also the same.  An edit is supplied to the standard to
clarify this.

EDITS:

[330:20] 13.7.16p5 Case (ii), after "with TARGET" insert
  "and, if TARGET is an internal procedure, they have the same host
   instance".

[330:22] Case (iii), after "same procedure" insert
  "and, if the procedure is an internal procedure, they have the same
   host instance".

SUBMITTED BY: Robert Corbett

HISTORY: 13-357   m202  F08/0103 submitted with four answers
         13-357r1 m202  Selected answer, added edits - passed by J3
                         meeting
         14-192    m204  Passed by J3 letter ballot 14-146
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0104
TITLE: IEEE Inquiry Functions
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

All references are to Fortran 2008 10-007r1.

On comp.lang.fortran Francis Coudert asked
 The Fortran 2008 standard defines an inquiry function
 as an "intrinsic function, or function in an intrinsic
 module, whose result depends on the properties of one
 or more of its arguments instead of their values".
 10-007r1 section 1.3.89 [11:27-30]

 I wonder: by that definition, how can the
 IEEE_SUPPORT_HALTING(FLAG) function from the
 IEEE_EXCEPTIONS intrinsic module be an inquiry function?
 Its result depends on the value of FLAG, not its
 properties.

QUESTIONS:

Question 1.

Are the functions

 IEEE_support_flag
 IEEE_support_halting
 IEEE_support_rounding
 c_associated
 c_funloc
 c_loc

intended to be inquiry functions?

Question 2.

Are they consistent with the definition of inquiry
functions?

Question 3.

Are they allowed in Specification expressions?

Question 4.

Are they allowed in Constant expressions?

ANSWERS:

Answer 1.

No.  These intrinsic module functions

 IEEE_support_flag
 IEEE_support_halting
 IEEE_support_rounding
 c_associated
 c_funloc
 c_loc

are not inquiry functions because their results depend on other than
the properties of their arguments.  Edits are provided to correctly
identify these functions as transformational:

[18:35-37] section 1.3.146
transformational function
intrinsic function, or function in an intrinsic module, that
is neither elemental nor an inquiry function

Answer 2.

No.  Their current classification is inconsistent with the definition
of inquiry functions.

Answer 3.

They should be allowed in specification expressions.  Edits are
provided to correct this.

Answer 4.

No. Only the 3 IEEE_* functions should be allowed in constant
expressions, not the 3 C_* functions.  Edits are provided to correct
this.

EDITS to 10-007r1:

[150:28+] section 7.1.11 Specification expression, paragraph 2,
after bullet (10), insert a new bullet:

"(nn) a reference to a transformational function from the
intrinsic module IEEE_ARITHMETIC (14), IEEE_EXCEPTIONS (14), or
ISO_C_BINDING (15.2), where each argument is a restricted
expression,"

[152:7-8] section 7.1.12 Constant expression, paragraph 1, replace
bullet (8):

"(8) a reference to the transformational function
IEEE_SELECTED_REAL_KIND from the intrinsic module
IEEE ARITHMETIC (14), where each argument is a constant
expression,"

with:

"(8) a reference to a transformational function from the
intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where
each argument is a constant expression,"

[408:1-] section 14.10 Summary of the procedures, paragraph 3,
in Table 14.1, for procedure IEEE_SUPPORT_ROUNDING: change the
"Class" column entry from "I" to "T".

[408:1-] section 14.10 Summary of the procedures, paragraph 3,
in Table 14.2, for procedures IEEE_SUPPORT_FLAG and
IEEE_SUPPORT_HALTING: change the "Class" column entries from
"I" to "T".

[418:16] section 14.11.27 IEEE_SUPPORT_FLAG (FLAG) or
IEEE_SUPPORT_FLAG (FLAG, X), paragraph 2:

"Inquiry function." -> "Transformational function."

[418:32] section 14.11.28 IEEE SUPPORT HALTING (FLAG),
paragraph 2:

"Inquiry function." -> "Transformational function."

[420:4] section 14.11.32 IEEE_SUPPORT_ROUNDING (ROUND_ VALUE) or
IEEE_SUPPORT_ROUNDING (ROUND_VALUE, X), paragraph 2:

"Inquiry function." -> "Transformational function."

[426:19] section 15.2.3.2 C_ASSOCIATED (C_PTR_1 [, C_PTR_2]),
paragraph 2:

"Inquiry function." -> "Transformational function."

[428:9] section 15.2.3.5 C_FUNLOC (X), paragraph 2:

"Inquiry function." -> "Transformational function."

[428:21] section 15.2.3.6 C_LOC (X), paragraph 2:

"Inquiry function." -> "Transformational function."

SUBMITTED BY: Dick Hendrickson

HISTORY: 14-100    m203  F08/0104 submitted
         14-100r1  m203  Answer proposed
         14-100r2  m203  Passed by J3 meeting
         14-192    m204  Passed as amended by J3 letter ballot 14-146
         N2047     m206  Passed as amended by WG5 ballot 8 N2042/43

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

NUMBER: F08/0105
TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute?
KEYWORDS: ASYNCHRONOUS, VALUE
DEFECT TYPE: Interpretation
STATUS: Passed by J3 letter ballot

QUESTION:

In the description of the VALUE attribute, [101:23-24] section
5.3.18p1, constraint C558 disallows the VOLATILE attribute with the
VALUE attribute:

  "C558 An entity with the VALUE attribute shall not have the
        ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or
        VOLATILE attributes."

But there is no prohibition of the ASYNCHRONOUS attribute with the
VALUE attribute.  Should this combination also be disallowed?

ANSWER:

No, the combination of VALUE and ASYNCHRONOUS attributes should not be
disallowed.  That is, the combination of VALUE and ASYNCHRONOUS
attributes should continue to be allowed.

A dummy argument with the VALUE attribute is not argument associated
with the corresponding actual argument.  Rather, it is associated with
an anonymous data object whose value is copied from the actual
argument before execution of the executable constructs of the
subprogram commences, and before expressions in the specification part
are evaluated.  Therefore, it can successfully take part in
asynchronous operations that both start and complete within that
procedure call, independently of whether the corresponding actual
argument has or has not the ASYNCHRONOUS attribute.

There is no problem if a dummy argument has the VALUE attribute and
the corresponding actual argument has the ASYNCHRONOUS attribute,
independently of whether the dummy argument has the ASYNCHRONOUS
attribute.  Subclause 9.6.4.1, paragraph 6 [220:13-15], prohibits an
actual argument that is part of a pending input/output storage
sequence affector from being associated with a dummy argument that has
the VALUE attribute.

EDIT to 10-007r1:

None.

SUBMITTED BY: Stan Whitlock

HISTORY: 14-109    m203  F08/0105 submitted - disallow failed
         14-109r1  m203  try allow - passed by J3 meeting
         14-192    m204  Failed J3 letter ballot #30 14-146
         14-269    m205  Revised answer - Passed by J3 meeting
         15-121    m206  Passed as amended by J3 letter ballot 14-279

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

NUMBER: F08/0106
TITLE:  MOVE_ALLOC for a remote array
KEYWORDS: allocation, coindexed
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Was it intended that MOVE_ALLOC can affect the allocation status of an
array on an image other than the executing image? An example is

     CALL MOVE_ALLOC(A,B[I]%A)

ANSWER:

No, it was not intended that the executing image can affect the
allocation status of an array on an image other than the executing
image. Edits are provided to correct this.

EDITS to 10-007r1:

13.7.118 MOVE_ALLOC(FROM,TO), para 3:

[372:18] In the description of FROM, after "It shall be allocatable",
add "and shall not be a coindexed object".

[372:19] In the description of TO, after "It shall be allocatable",
add "and shall not be a coindexed object".

SUBMITTED BY: John Reid

HISTORY: 14-119    m203  F08/0106 submitted - passed by J3 meeting
         14-192    m204  Passed by J3 letter ballot 14-146
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0107
TITLE: LOCK_TYPE, ultimate components, subcomponents, and coarrays
KEYWORD: LOCK_TYPE, ultimate components, subcomponents, coarrays
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

DISCUSSION:

Constraint C433 in subclause 4.5.2.1 reads:

C433 (R425) If EXTENDS appears and the type being defined has an
  ultimate component of type LOCK_TYPE from the intrinsic module ISO
  FORTRAN ENV, its parent type shall have an ultimate component of type
  LOCK TYPE.

This was intended to prevent compromising protection of objects of type
LOCK_TYPE by using type extension and polymorphism.

According to subclause 1.3.33.4, an ultimate component is a

  component that is of intrinsic type, a pointer, or allocatable; or an
  ultimate component of a nonpointer nonallocatable component of derived
  type

The type LOCK_TYPE is not intrinsic.  Therefore, if a type has a
nonallocatable component of type LOCK_TYPE, it does not have an ultimate
component of type LOCK_TYPE.  Therefore, constraint C433 fails to
protect entities of type LOCK_TYPE.

Constraint C433 prohibits reasonable constructions, such as extending
the type LOCK_TYPE, or extending a type that has an allocatable
component that has a component of type LOCK_TYPE, because the parent
type does not have an ultimate component of type LOCK_TYPE.

Constraint C1302 in subclause 13.8.2.16 reads:

C1302 A named variable of type LOCK TYPE shall be a coarray. A named
  variable with a noncoarray subcomponent of type LOCK TYPE shall be a
  coarray.

This was intended to require that components of type LOCK_TYPE, at any
level of component selection, be coarrays.

According to subclause 1.3.33.3, a subcomponent is a

  <structure> direct component that is a subobject of a structure

According to subclause 1.3.33.1, a direct component is

  one of the components, or one of the direct components of a nonpointer
  nonallocatable component.

The definition of the term "subcomponent" does not include components of
allocatable components.  Therefore, because of the use of the term
"subcomponent," if an object has an allocatable component that in turn
has a component of type LOCK_TYPE, C1302 can fail to require a component
of type LOCK_TYPE to be a coarray.

QUESTIONS:

Assume type LOCK_TYPE from ISO_Fortran_Env is accessible.

1. Is the definition of type One below standard conforming?

type, extends(LOCK_TYPE) :: One
  type(lock_type), allocatable :: LOCK
end type One

2. Is the definition of type Four below standard conforming?

type :: Two
  type(lock_type), allocatable :: LOCK[:]
end type Two

type :: Three
  type(two), allocatable :: L
end type Three

Type, extends(Three) :: Four
  type(lock_type), allocatable :: LOCK[:]
end type Four

3. Is the definition of type Six below standard conforming?

type :: Five
end type Five

type, extends(Five) :: Six
  type(two), allocatable :: L
end type Six

4. Is the declaration of the variable X below standard conforming?

  type :: Seven
    type(lock_type) :: L
  end type Seven

  type :: Eight
    type(seven), allocatable :: C
  end type Eight

  type(eight) :: X

ANSWERS:

1. This was intended to be permitted.  An edit is provided to repair
   the constraint on adding a LOCK_TYPE component during type
   extension.

2. This was intended to be permitted.  An edit is provided to repair
   the constraint on adding a LOCK_TYPE component during type
   extension.

3. This was not intended to be permitted.  An edit is provided to
   repair the constraint on adding a LOCK_TYPE component during type
   extension.

4. This was not intended to be permitted.  An edit is provided to
   repair the constraint on declaring objects which have a potential
   subobject of type LOCK_TYPE.

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)".

[61:27-29] 4.5.2.1 Syntax, C433,
           "ultimate" -> "potential subobject", twice.
           After "parent type"
           insert "shall be LOCK_TYPE or".

[127:8-9] 6.7.1.1 Syntax, C642, split into two constraints as follows:
  "C642 If an <allocate-object> is a coarray, the declared type of
        <source-expr> shall not be C_PTR or C_FUNPTR.

   C642a If an <allocate-object> is a coarray, the declared type of
         <source-expr> in a SOURCE= specifier shall not be LOCK_TYPE
         (13.8.2.16), nor shall it have a potential subobject
         component of type LOCK_TYPE."
{Fix subobject component, there is no problem with MOLD=.}

[127:18-19] 6.7.1.1, p4,
  "If" -> "If an ALLOCATE statement has a SOURCE= clause and an",
{There is no problem with MOLD=.  "subcomponent" works ok here because
 we have an object not a type.}

[399:17-18] 13.8.2.16 LOCK_TYPE, C1302,
            Change "with a noncoarray subcomponent"
            to "of a type that has a noncoarray potential subobject
                component".
{Constraints need to be about the type,}
ALTERNATIVE replace entire constraint with
  "C1302 A named variable shall be a coarray if its declared type is
         LOCK_TYPE or has a potential subobject component whose
         declared type is LOCK_TYPE."
{This makes it clear that we are talking about the declared type.}

SUBMITTED BY: Van Snyder

HISTORY: 14-154    m204  F08/0107 submitted
         14-154r3  m204  Revised

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

NUMBER: F08/0108
TITLE: ultimate components and coarrays
KEYWORD: ultimate components, coarrays
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

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
   according to C526 must be a dummy argument or have the 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
         14-258    m205  Passed as amended by J3 letter ballot #31
                          14-233r1
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0109
TITLE: LOCK_TYPE and unlimited polymorphic
KEYWORD: LOCK_TYPE, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

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, SAVE :: C[:]
  TYPE(LOCK_TYPE),      SAVE :: 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.  It cannot violate C1302 because
    that is a syntax constraint.  Only things that are statically
    detectable static properties of the program source text can be
    syntax constraints.  That means that "type" in C1302 can only mean
    "declared type".

    C is CLASS(*) so has no declared type and therefore cannot
    violate C1302.

    Edits are given to fix C1302 to say "declared type" explicitly to
    avoid this confusion.

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, C642,
          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.}

[399:17] 13.8.2.16 LOCK_TYPE, C1302
     "variable of type LOCK TYPE"
  -> "variable with declared type LOCK_TYPE".

SUBMITTED BY: Van Snyder

HISTORY: 14-164    m204  F08/0109 submitted
         14-164r3  m204  As amended, passed by J3 meeting
         14-258    m205  Failed the J3 letter ballot #31 14-233r1

  Malcolm Cohen's yes vote with comment on F08/0109:

    Bill Long writes:
      "The example Q3 has a variable, C, of type LOCK_TYPE that
       is not a coarray. This violates C1302.   Answer A3 is wrong."

    No, it cannot violate C1302 because that is a syntax constraint.
    Only things that are statically detectable static properties of
    the program source text can be syntax constraints.  That means
    that "type" in C1302 can only mean "declared type".

    C is CLASS(*) so has no declared type and therefore cannot
    violate C1302.

    C1302 ought to be fixed to say "declared type" explicitly, to
    avoid this confusion;

      [399:17] 13.8.2.16 LOCK_TYPE, C1302
            "variable of type LOCK TYPE"
         -> "variable with declared type LOCK_TYPE".

    Bill continues:
      "For the same reason the example Q4 is defective and answer
       A4 is wrong. "

    For the same reason, there is nothing wrong with Q4.

    Bill continues:
      "The example code in Q5 is also defective, although could be
       repaired by changing the declaration of X to

         TYPE(LOCK_TYPE),SAVE :: X[*]

      That seems to be sufficient to make answer A5 acceptable."

    X should certainly be explicitly made a coarray, but giving it
    SAVE seems unnecessary (this might be a main program or module,
    or might be a subprogram with a global SAVE, or X might be a
    dummy argument).  I guess it doesn't hurt though (other than
    looking a bit strange to have X saved but C not, so if we're
    going to SAVE one we should SAVE the other).

  Van Snyder's yes vote with Comment on F08/0109:

    "C643" in edit at [127:8-9] ought to be "C642"

  Result for F08/0109:

    /INTERP accepts Van's "C643 should be C642".  In Q5 make X a coarray
    and add SAVE to both C and X.  Make the edit to clarify C1302.
    /INTERP agrees with Malcolm that Q3 and Q4 are them ok.  This is a
    difficult subject and /INTERP believes that the J3 meeting should
    vote again on F08/0109 with these changes.

    F08/0109 failed the J3 letter ballot.

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

NUMBER: F08/0110
TITLE: Interdependence of specifier values in input/output statements
KEYWORD: specifier, input/output statement
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

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, POS=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 [243:3-5]

  "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 [243:6-8]

  "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.

According to 7.1.4p2 [139:3-4]

  "The evaluation of a function reference shall neither affect nor be
   affected by the evaluation of any other entity within the
   statement."

the INQUIRE statement is not prohibited because, although U is
assigned a value, it is not evaluated.

The INQUIRE statement was intended to be prohibited.  Edits are
provided to correct this mistake.

3. According to 9.12p6 [243:6-8]

  "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 [243:9-11]

  "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 [243:12-14]

  "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-5 9.12p5] Within the second sentence, provided by Corrigendum
2, replace "values of any <input-item> or" with "value of any".
Append ", or be affected by data transfer caused by that statement".
That sentence becomes

  "The value of an <internal-file-variable> or of a FMT=, ID=, IOMSG=,
   IOSTAT=, or SIZE= specifier shall not depend on the value of any
   <io-implied-do> <do-variable> in the same statement, or be affected
   by data transfer caused by that statement."

{Using "data transfer" instead of "<input-item>" covers the namelist
case.}

[243:6-7 9.12p6] Replace "value of any subscript or substring bound"
with "denotation".  Replace "depend ... <do-variable>" with "be
affected by the data transfer, the <io-implied-do> processing".  The
paragraph becomes

  "The denotation of a variable that appears in a specifier in an
   input/output statement 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> or
   <inquire-spec-list> in that statement."

After the paragraph, insert a note:

  NOTE 9.nn
  The semantics of how a variable is denoted is its "denotation";
  this includes such things as component and array element selection.
  Anything that affects this process is prohibited in this context;
  that includes the values of any subscripts used, and if the
  variable is specified by a pointer function reference, anything
  that affects the evaluation of that function.

{Using "data transfer" instead of "<input-item>" covers the namelist
case.}

[243:9 9.12p7] "Insert "ID=," before "IOSTAT".

{Not mentioned in a question, but was a problem.}

[243:12-14 9.12p8] Repairing the paragraph would make it equivalent
(if not identical) to 9.12p6, as revised above.  Therefore, delete
the paragraph.

SUBMITTED BY: Van Snyder

HISTORY: 14-193    m204  F08/0110 submitted
         14-193r1  m204  Revised
         14-272r1  m205  Passed by J3 meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0111
TITLE: Undefinition
KEYWORD: undefinition
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

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

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

NUMBER: F08/0112
TITLE: STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
KEYWORDS: STAT=, ERRMSG=, ALLOCATE, DEALLOCATE
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

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
         14-258    m205  Passed by J3 letter ballot #31 14-233r1
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0113
TITLE: Specifiers in image control statements
KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

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 value of
   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
         14-258    m205  Passed by J3 letter ballot #31 14-233r1
         N2047     m206  Passed by WG5 ballot 8 N2042/43

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

NUMBER: F08/0114
TITLE: Can LOCK_TYPE components have the POINTER attribute?
KEYWORD: LOCK_TYPE component, POINTER
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

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
         14-258    m205  Failed J3 letter ballot #31 14-233r1

  Malcolm Cohen's No vote on F08/0114:

    This is just the wrong decision.  People use pointers for all
    kinds of reasons, e.g. switching between two different structures,
    emulating optionality, etc.  We allow pointers to be followed
    cross-image from a coarray, which means that pointers with a
    potential subobject of type LOCK_TYPE would indeed be useful
    in such scenarios.

    We should not add this new restriction; rather, we should remove
    the misguided "style preference" that is currently badly expressed
    by C1302.

  Robert Corbett's yes vote with Comment on F08/0114:

    I find the text of the proposed edit difficult to read.  I prefer

      "C1302a A component that is of type LOCK_TYPE or that has a
              nonallocatable direct component of type LOCK_TYPE
              shall not have the POINTER attribute.".

  Result for F08/0114:

    /INTERP recommends that F08/0114 be returned to J3 for further
    consideration of Malcolm and Robert's comments along with checking
    other pending interps about LOCK_TYPE:

         F08/0045   constraints on entities of type LOCK_TYPE
         F08/0107   LOCK_TYPE, ultimate components, subcomponents, and
                      coarrays
         F08/0109   LOCK_TYPE and unlimited polymorphic

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

NUMBER: F08/0115
TITLE: ASYNCHRONOUS and argument passing
KEYWORD: ASYNCHRONOUS
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Consider

  PROGRAM Main
    INTEGER, ASYNCHRONOUS :: array(5) = -1
    OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read')
    CALL async_read(array)
    CALL fred(array(::2)) ! Problematic?
    WAIT (11)
    PRINT *, array
  CONTAINS
    SUBROUTINE async_read(array)
      INTEGER, ASYNCHRONOUS, INTENT(INOUT) :: array(:)
      READ (11, *, ASYNCHRONOUS='yes') array
    END SUBROUTINE
  END PROGRAM
  SUBROUTINE Fred (arg)  ! In general, an external procedure
    INTEGER :: arg(*)    ! Otherwise unused
    CONTINUE             ! In general, something that takes more time
  END SUBROUTINE

Is the call to "Fred" standard-conforming?

It is not excluded by 5.3.4p2, because 'array' is merely associated
with 'arg' in subroutine Fred, and not used in any executable
statement or specification expression there.  However, if copy-in/out
is used for argument passing and the actual i/o transfer occurs in
between the copy-in and copy-out, the wrong answers will be given.

ANSWER:

This program was not intended to be conforming.  An edit is provided
to correct this oversight.

EDITS:

[90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet,
        between "the variable" and "appears"
        insert "is a dummy argument or".

SUBMITTED BY: Nick Maclaren

HISTORY: 14-218    m205  F08/0115 submitted
         14-218r1  m205  Revised
         14-218r2  m205  Passed by J3 meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0116
TITLE: Interoperable procedures
KEYWORD: Interoperability, procedure
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

In all cases, Alf is a Fortran procedure like this:

    SUBROUTINE Alf (Arg) BIND(C,NAME='Alf')
        INTERFACE
            SUBROUTINE Arg () BIND(C)
            END SUBROUTINE Arg
        END INTERFACE
        CALL Arg
    END SUBROUTINE Alf

Q1. Consider

    extern void Bert (void) {
        ;
    }

    int main (void) {
        Alf(Bert);
    }

15.5.1p2 requires a procedure defined by means other than Fortran to
have the same binding label as the interface.  Function Bert() has a
binding label of 'Bert', but 15.5.2p2 states that the dummy argument
Arg has no binding label, therefore 15.5.1p2 is not satisfied.

Was this intended to be conforming?

Q2. Consider

    static void Fred (void) {
        ;
    }

    int main (void) {
        Alf(Fred);
    }

15.5.1p2 requires a procedure defined by means other than Fortran to
have a name that has external linkage as defined by 6.2.2 of ISO/IEC
9899:1999.  Function Fred() has no such name, as its definition has
internal linkage.  However, linkage in C affects only the visibility
of the external name, and has no application to either types or
values, whether in the form of function parameters or other pointers.

Was this intended to be conforming?

Q3. Consider

    extern inline void arg (void) {
        ;
    }

    int main (void) {
        Alf(Joe);
    }

C99 6.7.4 describes the inline specifier.  This does not prevent it
from having external linkage, but
  "An inline definition does not provide an external definition for
   the function"
i.e. despite having external linkage, there might be no external
definition that could be invoked from Fortran.

Was it not an oversight not to exclude inline in 15.5.1?

ANSWERS:

A1. Yes, this was intended to be conforming.  An edit is provided to
    correct this mistake.

A2. Yes, this was intended to be conforming.  An edit is provided to
    correct this mistake.

A3. A C function with no external definition is not "defined by
    means other than Fortran" so much as "not defined".  This was
    not intended to be conforming.  An edit is provided to clarify
    this situation.

EDITS:

[436:15] 15.5.1 Definition and reference of interoperable procedures,
         p1, Append sentence
  "A C function that has an inline definition and no external
   definition is not considered to be defined in this sense.".

In 15.5.1p2, apply these edits
[436:16] After "means other than Fortran," delete "it shall",
[436:17] Before "be describable" insert "it shall",
         after "the interface," insert "and",
[436:18-19] Before "have a name"
         insert "if it is accessed using its binding label, it shall"
         and begin a bullet sub-list,
         and make the "have the same" bullet the second sublist item.
This makes that whole paragraph read
  "If the procedure is defined by means other than Fortran,
   -- it shall be describable by a C prototype that is interoperable
      with the interface, and
   -- if it is accessed using its binding label, it shall
      - have a name that has external linkage as defined by 6.2.2 of
        ISO/IEC 9899:1999, and
      - have the same binding label as the interface."
{Note this wording uses "accessed" rather than "invoked" since it can
 be the argument of C_FUNPTR or the target in a procedure pointer
 assignment.}

SUBMITTED BY: Nick Maclaren

HISTORY: 14-221    m205  F08/0116 submitted
         14-221r1  m205  Revised
         14-221r2  m205  Further Revised - Passed by J3 meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0117
TITLE: TARGET and coindexed arguments
KEYWORD: TARGET, coindexing
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Is the following program conforming and required to print 10, 10, 10
and 123, 123, 123?

PROGRAM Main
    INTEGER, TARGET :: coarray(3)[*]
    coarray = 10*THIS_IMAGE()
    SYNC ALL
    IF (THIS_IMAGE() == 1) THEN
        SYNC ALL
        coarray = 123
        SYNC ALL
    ELSE IF (THIS_IMAGE() == 2) THEN
        CALL Fred(coarray(:)[1])
    ELSE
        SYNC ALL
        SYNC ALL
    END IF
CONTAINS
    SUBROUTINE Fred (arg)
        INTEGER, TARGET :: arg(:)
        PRINT *, arg
        SYNC ALL
        SYNC ALL
        PRINT *, arg
    END SUBROUTINE Fred
END PROGRAM Main


DISCUSSION:

This program is modifying an actual argument while it is associated
with a dummy argument.  That is normally prohibited by the anti-aliasing
rules in 12.5.2.13, but these do not operate in the TARGET dummy
argument case.  However, coindexed actual arguments are accessing
remote memory, so in general will be passed by copy-in/out; in this
case permitting aliasing is not reasonable.

ANSWER:

The program is not intended to be conforming.  Edits are provided to
correct this oversight.


EDITS:

[300] 12.5.2.13p1(3)(b) append to the end of the paragraph "or a
coindexed object".

[300] 12.5.2.13p1(4)(b) append to the end of the paragraph "or a
coindexed object".


SUBMITTED BY: Nick Maclaren


HISTORY: m205   14-223   F08/0117 submitted
         m205   14-223r1 Revised example and discussion - Passed by J3
                          meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0118
TITLE: Subobject of variable in variable definition context
KEYWORD: subobject, variable definition context
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Does this program conform to the Fortran 2008 standard?

  type :: T
    integer :: C
  end type T

  type(t), parameter :: V = T(41)

  associate ( W => V )
1   w%c = 42
  end associate

  end

DISCUSSION:

Because the selector is not permitted to appear in a variable
definition context, the associate-name is not permitted to appear in a
variable definition context.  However, that does not affect subobjects
of the associate-name.

ANSWER:

The associate-name is not permitted to appear in a variable definition
context because no interpretation is established; however, it should
be explicitly stated that this is not permitted.  An edit is provided
to clarify this.

EDITS:

[170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801,
         Between "<associate-name>" and "shall not appear"
         insert "or any subobject of <associate-name>".

[171:12] 8.1.3.3 Attributes of associate names, p2,
         Between "the associate name" and "shall not appear"
         insert "or any subobject of the associate name".

[184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836,
         Between "<associate-name>" and "shall not"
         insert "of any subobject of <associate-name>".

SUBMITTED BY: Van Snyder

HISTORY: 14-240r1  m205  F08/0118 submitted
         14-240r2  m205  Revised question and answer - Passed by J3
                          meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0119
TITLE: Branching to END BLOCK and END CRITICAL
KEYWORD: Branching, END BLOCK, END CRITICAL
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Do the GO TO statements in the following conform to the Fortran 2008
standard?

  go to 1
  block
1 end block

  go to 2
  critical
2 end critical

ANSWER:

Branching to an END BLOCK or END CRITICAL statement from outside the
construct was intended to be prohibited.  Edits are provided to
correct this omission.

EDITS:

[172:13+] 8.1.4 BLOCK construct, after p3 (before NOTE 8.5),
          Insert new paragraph
            "It is permissible to branch to an <end-block-stmt> only
             from within its BLOCK construct.".

[173:21+] 8.1.5 CRITICAL construct, after p3 (before NOTE 8.6),
          Insert new paragraph
            "It is permissible to branch to an <end-critical-stmt>
             only from within its CRITICAL construct.".

FUTURE REVISION:

A future revision could make all of these constraints, and combine
them into a single requirement as follows.

[170:36 8.1.3.2p3] Delete the paragraph.

[175:35-36 8.1.6.4p1] Delete "It is permitted ... DO construct."

[175:40 8.1.6.4p2] Delete "Transfer of control ... <inner-shared-do-
construct>."

[180:25 8.1.7.2p2] Delete "It is permissible ... IF construct."

[182:26 8.1.8.2p3] Delete the paragraph.

[185:26 8.1.9.2p9] Delete the paragraph.

[187:7+ 8.2.1p1+] Insert constraint:

"C847a If a branch target statement is an <end-associate-stmt>,
       <end-block-stmt>, <end-critical-stmt>, <end-do>,
       <end-if-stmt>, <end-select-stmt>, or <end-select-type-stmt>, the
       branching statement that references the label of that branch
       target statement shall be within the construct completed by that
       branch target statement."

SUBMITTED BY: Van Snyder


HISTORY: 14-242    m205  F08/0119 submitted
         14-242r1  m205  Revised question and answer
         14-242r2  m205  Fixed typo in example - Passed by J3 meeting
         15-121    m206  Passed as amended by J3 letter ballot 14-279

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

NUMBER: F08/0120
TITLE: Is the name of a procedure pointer a local identifier?
KEYWORDS: name procedure pointer
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Is the name of a procedure pointer a local identifier?

The list of classes of local identifiers given in paragraph 1
of subclause 16.3.1 of J3/10-007r1 (page 440) does not include
procedure pointers.

ANSWER:

Yes, if a procedure pointer is named, the name of the procedure
pointer is a local identifier.  An edit is provided to amend
the oversight.

EDITS:

[440:4, 16.3.1p1] Replace
 "named constants, named"
with
 "named constants, named procedure pointers, named".

SUBMITTED BY: Robert Corbett

HISTORY: 14-256    m205  F08/0120 submitted - Passed by J3 meeting
         15-121    m206  Passed as amended by J3 letter ballot 14-279

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

NUMBER: F08/0121
TITLE: Add to introduction defined operations in specification exprs
KEYWORDS: specification, restricted, defined operator
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Fortran 2003 7.1.6 (Specification expressions), says on 141:12:

A restricted expression is an expression in which each operation is
intrinsic

Fortran 2008 7.1.11 says on 150:8:

A restricted expression is an expression in which each operation is
intrinsic or defined by a specification function

This new feature is not called out in the Introduction but should be.

ANSWER:

This was an oversight. An edit to correct the problem is supplied.

EDIT to 10-007r1:

Introduction, page xv. Add to the "Data declaration" list in
paragraph 2: "A <defined-operator> can be used in a specification
expression."

SUBMITTED BY: Steve Lionel

HISTORY: 14-259    m205  F08/0121 submitted
         14-259r1  m205  In edit, replace "defined operator" with
                          "<defined-operator>" - Passed by J3 meeting
         15-121    m206  Passed as amended by J3 letter ballot 14-279

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

NUMBER: F08/0122
TITLE: Types with coarray components
KEYWORD: Coarrays, derived types
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTIONS:

Q1.  Consider

   Module m
     Type t
       Real,Allocatable :: co[:]
     End Type
     Type(t) x
     Real,Allocatable :: xco[:]
   Contains
     Subroutine dubious
       Volatile x
       Volatile xco
       ...
     End Subroutine
   End Module
   Program bad
     Use m
     Volatile x
     Volatile xco
     ...
   End Program

5.3.19 C560 says "The VOLATILE attribute shall not be specified for a
coarray that is accessed by use (11.2.2) or host (16.5.1.4)
association."

That means that the two "VOLATILE XCO" statements are not conforming.
However, the "VOLATILE X" statements have essentially the same effect,
but are unaffected by the constraint, which seems inconsistent.

Was this constraint also intended to apply to objects with coarray
components?

Q2.  Consider

    Program blockvolatile
      Type t
        Real,Allocatable :: co[:]
      End Type
      Type(t) x
      Real,Allocatable :: xco[:]
      ...
      Block
        Volatile x
        Volatile xco
      End Block

5.3.19 C561 says "Within a BLOCK construct (8.1.4), the VOLATILE
attribute shall not be specified for a coarray that is not a construct
entity (16.4) of that construct."

That means that VOLATILE XCO is not standard-conforming.  However, the
constraint apparently does not apply to X, so VOLATILE X is standard-
conforming, even though it has essentially the same effect as the
forbidden case.

Was this constraint intended also to apply to objects with coarray
components?

Q3. 5.3.19p1 says "A noncoarray object that has the VOLATILE attribute
    may be associated with an object that does not have the VOLATILE
    attribute..."; does this apply to objects with a coarray component?

Q4. 12.4.2.2p1 says "A procedure other than a statement function shall
    have an explicit interface if it is referenced and ... (2) the
    procedure has a dummy argument that ... (c) is a coarray, ...."

    Is this intended also to apply to objects with coarray components?

Q5.  Consider:

    Program volatility
      Type t
        Real,Allocatable :: co[:]
      End Type
      Type(t) :: x
      Type(t),Volatile :: y
      ...
      Call s1(x)
      Call s2(x) ! Dummy is volatile, X is not.
      Call s1(y) ! Y is volatile, dummy is not.
      Call s2(y)
    Contains
      Subroutine s1(a)
        Type(t) :: a
        ...
      End Subroutine
      Subroutine s2(b)
        Type(t),Volatile :: b
        ...
      End Subroutine
    End Program

12.5.2.8p1 says "If the dummy argument is a coarray, the corresponding
actual argument shall be a coarray and shall have the VOLATILE
attribute if and only if the dummy argument has the VOLATILE
attribute."

That means that if the program were passing the component CO directly
(and the TYPE(T) declarations in S1 and S2 were changed to REAL), the
second and third calls would not be conforming because of the VOLATILE
mismatch.

It seems inconsistent that there is no requirement for VOLATILE to
match when there are coarray components, since it has the same effect
that X%CO is VOLATILE in S2 but not in the caller, and Y%CO is
VOLATILE in the caller but not in S1.

Was this requirement also intended to apply to objects with coarray
components?

Q6. 12.8.1 C1289 says "All dummy arguments of an elemental procedure
    shall be scalar noncoarray dummy data objects and shall not have
    the POINTER or ALLOCATABLE attribute."

    Is this intended also to apply to objects with coarray components?

ANSWER:

A1. Yes, this constraint was intended to apply to objects with coarray
    components.  An edit is supplied to correct this omission.

A2. Yes, this constraint was intended to apply to objects with coarray
    components.  An edit is supplied to correct this omission.

A3. No, this does not apply to objects with coarray components, as
    there is no way of giving the noncoarray parts of the object the
    VOLATILE attribute without giving the coarray part the VOLATILE
    attribute, which is forbidden.  That the quoted text gives
    permission for a noncoarray to have the VOLATILE attribute does
    not override any other requirements in the standard.

A4. No.  A dummy argument that has a coarray component is still just
    an ordinary dummy argument, so this text does not apply.

A5. Yes, this requirement was intended to apply to objects with
    coarray components.  An edit is supplied to correct this omission.

A6. No.  A dummy argument that has a coarray component is still just
    an ordinary dummy argument, so this text does not apply.

EDITS:

[102:9] 5.3.19 VOLATILE attribute, C560,
        Between "for a coarray" and "that is accessed by use or"
        insert ",or a variable with a coarray ultimate component,".
{A1.}

[102:11] 5.3.19 VOLATILE attribute, C561,
         Between "for a coarray" and "that is not a construct entity"
         insert ",or a variable with a coarray ultimate component,".
{A2.}

[295:4+] 12.5.2.4 Ordinary dummy variables, p18+,
  "If the dummy argument has a coarray ultimate component, the
   corresponding actual argument shall have the VOLATILE attribute if
   and only if the dummy argument has the VOLATILE attribute."
{A5.}

SUBMITTED BY: Nick Maclaren

HISTORY: 14-228    m205  F08/0122 submitted
         14-228r1  m205  Revised questions with answers - Passed by J3
                          meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0123
TITLE: SPACING intrinsic
KEYWORDS: SPACING
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot

QUESTION:

Consider the following program

  Program test_spacing
    Real :: x, y, tiny_spacing, z
    x = Tiny(x)
    y  = Nearest(x,1.0)
    tiny_spacing = y - x
    If (tiny_spacing>0) Then
      ! Probably IEEE arithmetic with subnormals:
      ! the spacing y - x is representable.
    Else
      ! Probably no subnormals, so y - z is not representable.
      tiny_spacing = Tiny(x)
    End If
    z = Spacing(x)
    If (z/=tiny_spacing) Then
      Print *,'FAIL'
    Else
      Print *,'ok'
    End If
  End Program

Furthermore let us assume that the processor supports IEEE arithmetic
with subnormals, and that default REAL is IEEE single precision.

According to Fortran 95, the result for SPACING is:
  "If X is not zero, the result has the value b**(e-p), where b, e,
   and p are as defined in 13.7.1 for the model representation of X,
   provided this result is within range."
therefore the program is expected to print the value "ok".

However, according to Fortran 2008, the result for SPACING is:
  "If X does not have the value zero ..., the result has the value
   b**max(e-p,emin-1), where ..."
Unsurprisingly, e-p is not equal to max(e-p,emin-1) for smallish
numbers, and therefore the program would be expected to print the
value "FAIL".  However, there is no such incompatibility with Fortran
90/95 listed in clause 1, therefore the standard contradicts itself.
(The value specified in Fortran 2008 also contradicts the Description
of the function which says "Spacing of model numbers (13.4)", since
it does not even attempt to return that value.)

Is the new specification a deliberate incompatibility or a mistake?

DISCUSSION:

The description of SPACING was changed in Fortran 2003 by paper
01-361r2 "Comments on Section 13", which contains no justification for
this technical change and indeed does not even mention it is a
technical change - there is just the bare edit (buried in a huge list
of bare edits) with no indication as to why.  This would seem to
indicate that the technical change is an inadvertent error (presumably
the paper simply forgot about subnormal numbers and assumed the new
formula gave the same result as the old one).

ANSWER:

The new wording of SPACING inadvertently changed the return values
when IEEE subnormal values were available.  An edit is provided to
correct this mistake.

EDITS to 10-007r1:

[389:4-5] 13.7.157 SPACING (X), p5 Result Value,
          Change "max(e-p,emin-1)" to "e-p",
          After "that of X" insert
            ", provided this result is representable; otherwise the
             result is the same as that of TINY (X).",
          Change "; if there are two such values" to
          "If there are two extended model values equally near to X,".

This makes the whole paragraph read:

 If X does not have the value zero and is not an IEEE infinity or NaN,
 the result has the value b**(e-p), where b, e, and p are as defined
 in 13.4 for the value nearest to X in the model for real values whose
 kind type parameter is that of X, provided this result is
 representable; otherwise the result is the same as that of TINY (X).
 If there are two extended model values equally near to X, the value
 of greater absolute value is taken.  If X has the value zero, the
 result is the same as that of TINY (X).  If X is an IEEE infinity,
 the result is an IEEE NaN.  If X is an IEEE NaN, the result is that
 NaN."

where "b**(e-p)" represents the typesetting of $b^{e-p}$.

SUBMITTED BY: Malcolm Cohen

HISTORY: 14-263    m205  F08/0123 submitted - Passed by J3 meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0124
TITLE: Coindexed object with polymorphic subcomponent
KEYWORD: Coindexed object, polymorphic subcomponent
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:

Consider the following type definitions and object declarations:

  Type t1
    Class(*),Allocatable :: bad
  End Type

  Type t2
    Type(t1),Allocatable :: oops
  End Type

  Type(t1) x[*]
  Type(t2) y[*]

Do the following subroutine calls conform to the Fortran 2008 standard?

  Call s1(x[2])
  Call s2(y[2])

DISCUSSION:

If Y[2]%OOPS and Y[2]%OOPS%BAD are both allocated they are subobjects,
but only OOPS is a subcomponent of Y[2].  Since OOPS is not
polymorphic and BAD is not a subcomponent, this clearly does not
violate C617.  That seems inconsistent since in both cases a copy of
the coindexed variable would necessarily copy the polymorphic BAD
component.

ANSWER:

The intent of C617 was to prevent copying a polymorphic subobject of
a coindexed object.  Since a subobject is not always a subcomponent,
an edit is provided to correct the mistake of using the term
"subcomponent" in C617.

EDITS:

[6:7+] After 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"
{We need a new term to describe this properly.}

[119:13 C617] Replace "subcomponent"
              with "potential subobject component".

SUBMITTED BY: Van Snyder

HISTORY: 14-262    m205  F08/0124 submitted - Passed by J3 meeting
         15-121    m206  Passed by J3 letter ballot 14-279

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

NUMBER: F08/0125
TITLE: Definition of objects of type LOCK_TYPE with pointer subobjects
KEYWORD: pointer subobject, variable definition context, LOCK_TYPE
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Does the following conform to the Fortran 2008 standard?

  type :: t
    type(lock_type), pointer :: P = NULL()
  end type t

  type(t), parameter :: N = t(null())
  type(t) :: V
  type(lock_type), target :: L

1 nullify ( v%p )

2 v%p => l

3 v = n

ANSWER:

Constraint C1303 prohibits a variable of type LOCK_TYPE from appearing
in a variable definition context, with a few exceptions that do not
include statements 1 and 2.  Subclause 16.6.7 specifies that the
appearance of a variable as a <pointer-object> in a <nullify-stmt>, or
as a <data- pointer-object> or <proc-pointer-object> in a <pointer-
assignment-stmt>, is a variable association context.  Therefore
statements 1 and 2 do not conform to the Fortran 2008 standard.

The appearance of a <pointer-object> in a <nullify-stmt>, or of a <data-
pointer-object> or <proc-pointer-object> in a <pointer-assignment-stmt>,
are pointer association contexts, and are listed as such in subclause
16.6.8; they ought not to be listed as variable definition contexts in
subclause 16.6.7.

{The above proposition was advocated in 14-139r3, accepted at meeting
204, and incorporated into 14-007r2.  Therefore, statements 1 and 2 will
conform to the next revision of the Fortran standard.  Whether
statements 1 and 2 ought to be included in the present question can be
decided in due course.}

Constraint C1304 prohibits a variable with a subobject of type LOCK_TYPE
from appearing in a variable definition context, with a few exceptions
that do not include statement 3.  Therefore statement 3 does not conform
to the Fortran 2008 standard.

{The proposition that the prohibition should only apply to variables
that have nonpointer subobjects of the type EVENT_TYPE being developed
in TS 18508 was accepted, and incorporated into 14-231/N2027.}

Statements 1-3 are harmless, and ought to be permitted.  Edits are
provided to correct this.

EDITS:

[399:22 C1304] Insert "nonpointer" before "subobject".

{A change parallel to this, concerning EVENT_TYPE, is already
incorporated in 14-231/N2027.}

EDITS already applied in 14-007r2:

[312:33+ C1283(1)+] Insert a list item

  "(1a) in a pointer association context (16.6.8),"

{This is a knock-on effect due to deleting pointer association contexts
from the list of variable definition contexts.  It recovers items (2),
(3) and (12) from 16.6.7p1, which are deleted below.}

[313:1-2 C1283(5)]  Delete "with INTENT(OUT) or INTENT(INOUT)" from item
(6) because it is covered by 16.6.7p1(12).

[456:44-45 16.6.7p1(2-3)] Delete list items (2) and (3) because they are
not variable definition contexts, and do not apply to nonpointer
variables.

[445:11 16.6.7p1(12)] Append "is not a pointer and" after "dummy
argument", because an actual argument pointer corresponding to a dummy
argument pointer is not a variable definition context, and doesn't apply
to nonpointer variables.

SUBMITTED BY: Van Snyder

HISTORY: 14-241r1  m205  F08/0125 submitted

Note:  Interps that also ask about LOCK_TYPE:

  *  P E F08/0045   constraints on entities of type LOCK_TYPE

  *  P E F08/0107   LOCK_TYPE, ultimate components, subcomponents, and
                      coarrays
  *  P E F08/0109   LOCK_TYPE and unlimited polymorphic

  *  P E F08/0114   Can LOCK_TYPE components have the POINTER attribute?

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