ISO/IEC JTC1/SC22/WG5 N2098
										   
    Defect reports that led to Corrigendum 4 and responses to them

	                            Stan Whitlock
Date: 2016 Feb 21

Note N:
     d == done
     * == 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
       C4   In F2008 Corrigendum 4

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

d C4 I F03/0042   IEEE funny values and Standard real generic
                    intrinsic procedures
d C4 I F08/0099   VOLATILE in specification expressions
d C4 E F08/0100   IMPORT statement and prior explicit declaration
d C4 E F08/0101   NAMELIST and multiple occurrences of a variable
d C4 E F08/0102   MERGE and polymorphism
d C4 E F08/0103   Pointers to internal procedures with different host
                    instances
d C4 E F08/0104   IEEE Inquiry Functions
d C4 I F08/0105   Is the ASYNCHRONOUS attribute allowed with the
                    VALUE attribute?
d C4 E F08/0106   MOVE_ALLOC for a remote array
d C4 I F08/0108   ultimate components and coarrays
d C4 E F08/0109   LOCK_TYPE and unlimited polymorphic
d C4 E F08/0112   STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
d C4 E F08/0113   Specifiers in image control statements
d C4 E F08/0115   ASYNCHRONOUS and argument passing
d C4 E F08/0116   Interoperable procedures
d C4 E F08/0117   TARGET and coindexed arguments
d C4 E F08/0118   Subobject of variable in variable definition context
d C4 E F08/0119   Branching to END BLOCK and END CRITICAL
d C4 E F08/0120   Is the name of a procedure pointer a local identifier?
d C4 E F08/0121   Add to introduction defined operations in specification
                   exprs
d C4 E F08/0122   Types with coarray components
d C4 E F08/0123   SPACING intrinsic
d C4 E F08/0124   Coindexed object with polymorphic subcomponent
d C4 E F08/0126  Can cobounds be referenced in the same type
                  declaration?
d C4 E F08/0127  May an initial line begin with a semicolon?
d C4 E F08/0129  Is CLASS(type) required to refer to a prior type
                  definition?
d C4 E F08/0130  Does coarray allocation sync even with stopped
                  images?
d C4 E F08/0131  Are the changes to C_LOC in the 2010 revision
                  intentional?
d C4 E F08/0132  Can a procedure pointer be declared with an
                  interface block?
d C4 E F08/0133  Is unallocated actual associated with
                  nonallocatable dummy OK?
d C4 E F08/0134  <stat-variable> in an image control statement
d C4 E F08/0135  Vector subscripted actual makes VALUE dummy
                  undefinable?
d C4 E F08/0136  Argument correspondence with VALUE and
                  ASYNCHRONOUS
d C4 E F08/0137  Result of TRANSFER when MOLD is an array with
                  element size zero
d C4 C F08/0138  Type extension in submodules
d C4 E F08/0139  Is the name of an external procedure that has a
                  binding label a local identifier?
d C4 E F08/0140  Assign to deferred-length coindexed character variable
d C4 E F08/0141  Can a statement function have a variable-length PDT
                  result?
d C4 E F08/0142  Is useless module extension permitted?
d C4 E F08/0143  May a pure procedure have an INTENT(OUT) polymorphic
                  component?
d C4 E F08/0144  Is nonadvancing I/O allowed during execution of DO
                  CONCURRENT?
d C4 E F08/0145  Can initial-data-target be coindexed?
d C4 E F08/0147  Is generic resolution of elemental assignment done
                  at runtime?
d C4 E F08/0148  Pointer subobject in structure constructor in pure
                  procedure

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

NUMBER: F03/0042
TITLE:  IEEE funny values and Standard real generic intrinsic
        procedures
KEYWORDS: IEEE-754, real math library
DEFECT TYPE: Interpretation
STATUS: In F2008 Corrigendum 4

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 erroneous text quoted from 13.7 in Fortran 2003 has been revised
in Fortran 2008, and again by Corrigendum 2 for Fortran 2008, and now
no longer conflicts with the IEEE-754 standard.

To specify the results of all the intrinsics for non-normal values is
beyond the scope of an interpretation.  This could be considered for a
future revision.

EDITS to 10-007r1:

None.

SUBMITTED BY: Fred Tydeman

HISTORY: 05-121r1  m171  F03/0042 submitted
         15-248    m208  Revised answer and edits - passed by J3 meeting
         16-103    m209  Passed by J3 letter ballot #34 16-101
         N2087     m209  Passed by WG5 ballot #10 N2085/86
         N2102     m209  No edits in F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0099
TITLE: VOLATILE in specification expressions
KEYWORD: VOLATILE, specification expression
DEFECT TYPE: Interpretation
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

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
         N2102     m209  No edits in F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0100
TITLE: IMPORT statement and prior explicit declaration
KEYWORD: IMPORT statement, prior explicit declaration
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0101
TITLE: NAMELIST and multiple occurrences of a variable
KEYWORD: NAMELIST
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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.

EDITS to 10-007r1:

[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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0102
TITLE: MERGE and polymorphism
KEYWORD: MERGE, polymorphic
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0103
TITLE: Pointers to internal procedures with different host instances
KEYWORD: internal procedure, procedure pointer, host instance
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0104
TITLE: IEEE Inquiry Functions
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 item (10), insert a new item:

"(10a) 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
item (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
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0105
TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute?
KEYWORDS: ASYNCHRONOUS, VALUE
DEFECT TYPE: Interpretation
STATUS: In F2008 Corrigendum 4

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 storage sequence
affector from being associated with a dummy argument that has the
VALUE attribute.

EDITS 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
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  No edits in F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0106
TITLE:  MOVE_ALLOC for a remote array
KEYWORDS: allocation, coindexed
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0108
TITLE: ultimate components and coarrays
KEYWORD: ultimate components, coarrays
DEFECT TYPE: Interpretation
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

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
         N2102     m209  No edits in F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0109
TITLE: LOCK_TYPE and unlimited polymorphic
KEYWORD: LOCK_TYPE, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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.

    Note that it is impossible to actually use the allocated target of
    C in any useful fashion; SELECT TYPE cannot access it because the
    associate-name would be a named lock variable, but it is not a
    coarray so that would not be allowed.

    So this is permitted, but useless, and because it is useless it is
    also harmless.  A future revision could disallow this without the
    concomitant incompatibility inconveniencing any programs.

A4. Pointer assignment to C is permitted.

    As in A3, this is useless but harmless.  A future revision could
    disallow this without the concomitant incompatibility
    inconveniencing any programs.

A5. This statement was intended to be permitted.  An edit is supplied
    to correct the requirements.

Note that the term "potential subobject component" is defined in interp
F08/0124 and will be in F2008 Corrigendum 4:

  [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".

EDITS to 10-007r1:

[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
  "C642a (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,
  Instead of the edit in Corr. 2, make this change to the 10-007r1 text:

    Change "If <allocate-object> is" -> "If an ALLOCATE statement
            has a SOURCE= specifier and an <allocate-object> that is".
    {There is no problem with MOLD=.  "subcomponent" works ok here
     because we have an object not a type.}

  so p4 reads:

    "If an ALLOCATE statement has a SOURCE= specifier and an
     <allocate-object> that is a coarray, <source-expr> shall not have a
     dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or have a
     subcomponent whose dynamic type is LOCK_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
         15-253    m208  Revised - passed by J3 meeting
         16-103    m209  Passed as amended by J3 letter ballot #34 16-101
         N2087     m209  Passed as amended by WG5 ballot #10 N2085/86
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0112
TITLE: STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
KEYWORDS: STAT=, ERRMSG=, ALLOCATE, DEALLOCATE
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0113
TITLE: Specifiers in image control statements
KEYWORDS: STAT=, ERRMSG=, ACQUIRED_LOCK=, image control
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0115
TITLE: ASYNCHRONOUS and argument passing
KEYWORD: ASYNCHRONOUS
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet,
        between "the variable" and "appears"
        insert "is a dummy argument or"
        and insert a comma after "scoping uinit".

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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0116
TITLE: Interoperable procedures
KEYWORD: Interoperability, procedure
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0117
TITLE: TARGET and coindexed arguments
KEYWORD: TARGET, coindexing
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[300:14] 12.5.2.13p1(3)(b) after "target other than" insert "a
coindexed object or".

[300:22] 12.5.2.13p1(4)(b) after "target other than" insert "a
coindexed object or".

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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0118
TITLE: Subobject of variable in variable definition context
KEYWORD: subobject, variable definition context
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 )
    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 to 10-007r1:

[170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801,
         Change "<associate-name> shall not appear"
         to "neither the <associate-name> nor any subobject thereof
             shall appear".

[171:12] 8.1.3.3 Attributes of associate names, p2,
         Change "the associate name shall not appear"
         to "neither the associate name nor any subobject thereof
             shall appear".

[184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836,
         Change "<associate-name> shall not appear"
         to "neither the <associate-name> nor any subobject thereof
             shall appear".

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
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0119
TITLE: Branching to END BLOCK and END CRITICAL
KEYWORD: Branching, END BLOCK, END CRITICAL
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0120
TITLE: Is the name of a procedure pointer a local identifier?
KEYWORDS: name procedure pointer
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[440:4, 16.3.1p1] In item (1) after "named constants,"
insert "named procedure pointers,".

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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0121
TITLE: Add to introduction defined operations in specification exprs
KEYWORDS: specification, restricted, defined operator
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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.

EDITS 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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0122
TITLE: Types with coarray components
KEYWORD: Coarrays, derived types
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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 to 10-007r1:

[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+, add paragraph
  "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
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0123
TITLE: SPACING intrinsic
KEYWORDS: SPACING
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

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" where e and p are in italics.
          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}$ and throughout
the edits, "b", "e" and "p" are in italics.

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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0124
TITLE: Coindexed object with polymorphic subcomponent
KEYWORD: Coindexed object, polymorphic subcomponent
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4
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 to 10-007r1:

[6:7+] After the definition of <<parent component>> (1.3.33.2), 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
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0126
TITLE: Can cobounds be referenced in the same type declaration?
KEYWORDS: Cobounds, type declaration
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Do the following declarations conform to the Fortran 2008 standard?

  integer :: A[5,*] = ucobound(a,1) )
  integer :: C[5,ucobound(c,1),*]
  integer :: B[5,*], C[ucobound(b,1),*], D(ucobound(c,1))

ANSWER:

7.1.11p8 says

  "If a specification expression includes a specification inquiry that
   depends on a type parameter or an array bound of an entity specified
   in the same <specification-part>, the type parameter or array bound
   shall be specified in a prior specification of the
   <specification-part>...."

This does not establish an interpretation for any of the declarations.

The intent of interpretation F95/000090 was that the third one be
allowed, while the first and second be prohibited.0104

Edits are provided to correct this oversight.

EDITS to 10-007r1:

[10-007r1:151:7-8 7.1.11p8] Replace "a type parameter or an array bound"
with "a type parameter, array bound, or cobound"
and replace "the type parameter, or array bound"
with "the type parameter, array bound, or cobound".

SUBMITTED BY: Van Snyder

HISTORY: 15-102    m206  F08/0126 submitted
         15-102r2  m206  Passed by J3 meeting
         15-187    m207  Passed by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0127
TITLE: May an initial line begin with a semicolon?
KEYWORDS: Semicolon
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

The Introduction to ISO/IEC 1539-1:2010, page xvi, states
  "A line in the program is permitted to begin
   with a semicolon."

Therefore, do the following 3 lines constitute a valid program.
;PROGRAM bad
PRINT *,'No'
END PROGRAM

ANSWER:

No, the example is not a valid program as it does not satisfy the
syntax rules and constraints.  As stated in 3.3.2.5 and 3.3.3.4, a
semicolon may be used to terminate a statement.  That is not the
case in the example, since there is no statement before the semicolon.

The semicolon does not appear anywhere else in the Fortran syntax and
therefore the example does not conform.

An edit is supplied to the Introduction to clarify the change in
Fortran 2008.

EDITS to 10-007r1:

[xvi] Introduction, bullet "Programs and procedures:",
      Replace
        "A line in the program is permitted to begin with a semicolon."
      with
        "A free form continuation line can begin with zero
         or more blanks followed by a semicolon."

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-105    m206  F08/0127 submitted - passed by J3 meeting
         15-187    m207  Passed as amended by J3 letter ballot 15-159
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0129
TITLE: Is CLASS(type) required to refer to a prior type definition?
KEYWORDS: CLASS, type definition
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Does the CLASS(T) declaration of X in the following conform?

recursive subroutine S ( N, X )
  integer :: N
  class(t), optional :: X
  type :: T
    integer :: Q
  end type T
...

ANSWER:

Although subclause 4.3.1.3 does not require the <derived-type-spec> in a
CLASS specifier to refer to a previously-defined type, it was intended
that CLASS declarations with <derived-type-spec> be parallel to TYPE
declarations.  In a TYPE declaration (4.3.1.2), the specified derived
type is required to be previously defined, or accessed by use or host
association.  Therefore the example ought not to conform.  Edits are
provided to correct this oversight.

EDITS to 10-007r1:

[52:6+] 4.3.1.3 CLASS, p1+, insert new paragraph:

"Where a data entity other than a component is declared explicitly using
the CLASS specifier to be of derived type, the specified derived type
shall have been defined previously.  If the data entity is a function
result, the derived type may be specified in the FUNCTION statement
provided the derived type is defined within the body of the function or
is accessible there by use or host association.  If the derived type is
specified in the FUNCTION statement and is defined within the body of
the function, it is as if the function result variable were declared
with that derived type immediately following its <derived-type-def>."

{This is essentially identical to 4.3.1.2p1, except for the replacement
of "TYPE" with "CLASS" and the addition of "other than a component"
(4.3.1.2p1 does not mention components, but it ought to because
otherwise it would contradict C440), but that's a different question.}

SUBMITTED BY: Van Snyder

HISTORY: 15-127    m206  F08/0129 submitted
         15-127r1  m206  Passed by J3 meeting
         15-187    m207  Passed as amended by J3 letter ballot 15-159
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0130
TITLE: Does coarray allocation sync even with stopped images?
KEYWORDS: ALLOCATE, DEALLOCATE, coarray, synchronization, stopped
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Example 1: Consider the trivial program

  Program m206c7e1
    Use Iso_Fortran_Env
    Implicit None
    Real, Allocatable :: x(:)[:]
    Integer :: me[*],i
    Integer stat
    me = This_Image()
    If (Num_Images()<3) Error Stop 'Need at least 3 images'
    If (me==1) Then
      Stop 'Image 1 is now stopping'
    End If
    Allocate(x(100)[*],Stat=stat)
    !
    If (me==2) Print *,'Arrived'                !***A
    !
    If (stat==0) Error Stop 'INCONCEIVABLE'
    If (stat/=Stat_Stopped_Image) Error Stop 'Bad STAT'
    !
    Do i=1,Num_Images()
      If (me[i]/=i) Error Stop 'me not right?'  !***B
    End Do
  End Program

Q1. On images other than image 1, does execution ever reach the
    statement with comment "!***A"?

    6.7.1.2 Execution of an ALLOCATE statement, p4 says
      "When an ALLOCATE statement is executed for which an
       allocate-object is a coarray, there is an implicit
       synchronization of all images.  On each image, execution of the
       segment (8.5.2) following the statement is delayed until all
       other images have executed the same statement the same number
       of times."

    The second sentence seems to say that execution on images>1 is
    delayed forever, since image 1 will never execute that ALLOCATE
    statement.

Example 2: Consider the program

  Program m206c7e2
    Use Iso_Fortran_Env
    Implicit None
    Real(real32), Allocatable :: x(:,:,:,:)[:],y(:,:,:,:)
    Integer :: me[*],i
    Integer stat
    me = This_Image()
    If (Num_Images()<3) Error Stop 'Need at least 3 images'
    If (me==1) Then
      Allocate(y(1000,1000,1000,1000))                !***C
    End If
    Allocate(x(1000,1000,1000,1000)[*],Stat=stat)     !***D
    !
    If (me==1 .And. stat==0) Error Stop 'Inconceivable!'
    !
    If (stat==0) Print *, 'ALLOCATE ok on image', me  !***E
    !
    Do i=1,Num_Images()
      If (me[i]/=i) Error Stop 'me not right?'        !***F
    End Do
  End Program

For purposes of discussion, let us assume that each image has 6
Terabytes of memory available to it for dynamic allocation.

The ALLOCATE statement commented "!***C" will allocate 4 terabytes of
memory on image 1.  Execution of the ALLOCATE statement commented
"!***D" will attempt to allocate 4 terabytes on each image; this will
fail on image 1 as there is insufficient memory available, but could
succeed on other images.

Q2. Is the success of an ALLOCATE statement the same on every image,
    or may it fail on some images and succeed on others?  That is,
    might the statement commented "!***E" execute the PRINT on some
    images (but not all).

Q2 continuation:
    If the answer is that the ALLOCATE must either succeed or fail on
    all images, can the STAT= value differ by image (for example,
    might a processor return a different STAT= code for "no memory on
    this image" and "no memory on some other image").

Example 3: Consider the program

  Program m206c7e3
    Use Iso_Fortran_Env
    Implicit None
    Real, Allocatable :: x(:)[:]
    Integer :: me[*],i
    Integer stat
    me = This_Image()
    If (Num_Images()<3) Error Stop 'Need at least 3 images'
    If (me==1) Then
      Call do_something_that_takes_a_very_long_time
    End If
    Allocate(x(100)[*],Stat=stat)               !***G
    !
    If (stat==0) Error Stop 'INCONCEIVABLE'
    !
    Do i=1,Num_Images()
      If (me[i]/=i) Error Stop 'me not right?'  !***H
    End Do
  End Program

Let us imagine that the processor operates some form of "timeout"
mechanism, for example, if an image fails to reach a synchronization
point within an hour of the first image reaching that statement, an
error is returned.  (If the slow image subsequently reaches that
statement, one might conjecture that it will also get an error, but
probably STAT_YOU_ARE_TOO_SLOW rather than STAT_TIMEOUT).

In the example above, let us assume that the ALLOCATE statement
commented "!***G" fails, e.g. with a timeout error as we imagined above.

Q3. After resolution of question 1, which images are synchronized
    after execution of an ALLOCATE statement that fails?  That is,
    is execution of the statements commented "!***B" (in Q1), "!***F"
    (in Q2) and "!***H" (above) permitted, or are they impermissible
    references to variables in unordered segments?

    In the case of "!***B", one might conjecture that all the
    non-stopped images are synchronized.

    In the case of "!***F" the text of the standard appears to require
    that image 1 has to wait for all the other images, but it might
    equally be conjectured that that is a mistake and that since it
    knows straightaway that it cannot satisfy the memory allocation it
    should be allowed to return straightaway without synchronizing,
    i.e. the "!***F" is not allowed.

    In the case of "!***H", image 1 has still not even reached the
    ALLOCATE statement (after an hour of the others waiting), so it
    would seem that it is impossible for it to have synchronized as
    required by the standard, and therefore that (for i==1 at least)
    the execution of "!***H" is not allowed.

Q4. When allocation of a coarray is involved, and an error occurs
    (e.g. as in the examples above, plus other cases), under what
    situations does the coarray in question become allocated?

    In particular, can a coarray be allocated on some images but not
    others?  If the answer is that the coarray never becomes
    allocated, that means that in the case of a stopped image, the
    remaining images cannot allocate any coarray.

Q5. Do the answers to Q1-Q4 also apply to DEALLOCATE statements?

ANSWER:

A1. In the case of stopped images, the requirement in 6.7.1.2 was only
    intended to apply to the non-stopped images.  An edit is provided
    to correct this mistake.

A2. Allocation of a coarray was intended only to succeed if it
    succeeds on all images.  An edit is provided to add this missing
    requirement.
(A2 continuation)
    There was not intended to be any requirement that a nonzero STAT=
    value be the same on each image.  No edit is provided to add such
    a requirement.

A3. After execution of an ALLOCATE statement that returns an error
    other than STAT_STOPPED_IMAGE, there was not intended to be any
    requirement for synchronization.  An edit is provided to correct
    this mistake.

A4. The coarray can become allocated on an image if and only if it can
    become allocated on all other images.  An edit is provided to add
    this requirement.  The consequence in the case of a stopped image
    is indeed that no image can subsequently change the allocation
    status of any coarray.

A5. Yes, the answers also apply to DEALLOCATE statements.
    Corresponding edits are supplied.

EDITS to 10-007r1:

[128:15-17] 6.7.1.2 Execution of an ALLOCATE statement, p4,
  Change "On each image"
  to     "If no error condition other than STAT_STOPPED_IMAGE occurs"
  Change "all other images"
  to     "all non-stopped images".
{A1,A3: Synchronization only applies to successful allocations and to
         allocations that fail only due to STAT_STOPPED_IMAGE.}
  Append a sentence requiring allocation success consistency for
  coarrays, making the whole paragraph read:
    "When an ALLOCATE statement is executed for which an
     <allocate-object> is a coarray, there is an implicit
     synchronization of all images.  If no error condition other than
     STAT_STOPPED_IMAGE occurs, execution of the segment (8.5.2)
     following the
     statement is delayed until all non-stopped images have executed
     the same statement the same number of times.  The coarray shall
     not become allocated on an image unless it is successfully
     allocated on all non-stopped images."
{A2,A4: Last sentence is the consistency requirement.}

[131:16-19] 6.7.3.2 Deallocation of allocatable variables, p11,
  Change "On each image"
  to     "If no error condition other than STAT_STOPPED_IMAGE occurs"
  Change "all other images"
  to     "all non-stopped images".
  Append a sentence requiring deallocation consistency, making the
  whole paragraph read:
    "When a DEALLOCATE statement is executed for which an
     <allocate-object> is a coarray, there is an implicit
     synchronization of all images.  If no error condition other
     than STAT_STOPPED_IMAGE occurs,
     execution of the segment (8.5.2) following the statement is
     delayed until all non-stopped images have executed the same
     statement the same number of times.  If the coarray is a dummy
     argument, its ultimate argument (12.5.2.3) shall be the same
     coarray on every image.  The coarray shall not become deallocated
     on an image unless it is successfully deallocated on all 
     non-stopped images."

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-133    m206  F08/0130 submitted
         15-133r1  m206  Passed by J3 meeting
         15-187    m207  Passed as amended by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2094     m209  Modified by 1st Corrigendum 4 ballot N2088/89/90
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0131
TITLE: Are the changes to C_LOC in the 2010 revision intentional?
KEYWORDS: C_LOC, interoperability
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

The description of C_LOC in the intrinsic module ISO_C_BINDING permits
noninteroperable array arguments that are contiguous, provided the
type and kind are interoperable.  This was not permitted by the
previous revision of ISO/IEC 1539-1, which required all type
parameters to be interoperable (and only exempted allocatable arrays
from the "interoperable variable" requirement); however this is not
listed in the Introduction as a change.

For example, each of the following is apparently permitted as
arguments to C_LOC by the requirements in Fortran 2008 but not in
Fortran 2003:
  CHARACTER(13,C_char),TARGET :: x(100)
  CHARACTER(14,C_char),TARGET :: y
  REAL(C_float),CONTIGUOUS :: dummy1(:)
  INTEGER(C_int),CONTIGUOUS,POINTER :: z(:)
(the CONTIGUOUS attribute does not exist in Fortran 2003).
and also
  REAL(C_float) :: dummy2(:)
  INTEGER(C_int),POINTER :: z2(:)
when dummy1 is argument-associated with a contiguous array, and z2 is
pointer-associated with a contiguous array.

Was this change intended?

ANSWER:

Yes, this change was intentional.  An edit is provided to add this to
the Introduction.

EDITS to 10-007r1:

[xvi] Introduction, "Intrinsic modules" bullet point,
  Before "The function C_SIZEOF"
  insert new sentence
    "A contiguous array variable that is not interoperable but which has
     interoperable type and kind type parameter (if any), and a scalar
     character variable with length>1 and kind C_CHAR, can be used as
     the argument of the function C_LOC in the intrinsic module
     ISO_C_BINDING, provided the variable has the POINTER or TARGET
     attribute."

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-132    m206  F08/0131 submitted
         15-132r1  m206  Revised edits
         15-132r2  m206  Revised question - passed by J3 meeting
         15-187    m207  Passed by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0132
TITLE: Can a procedure pointer be declared with an interface block?
KEYWORDS: procedure pointer, interface block
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider the program

  PROGRAM c11
    INTERFACE
      REAL FUNCTION F()
      END FUNCTION
    END INTERFACE
    POINTER F
    EXTERNAL G
    F => G
    PRINT *,F()
  END PROGRAM
  REAL FUNCTION G()
    G = 206
  END FUNCTION

According to 12.4.3.2 paragraph 5, F is an external procedure (and
seems to be missing).  There is no mention of the possibility of a
procedure pointer in the subclause on interface blocks.

Is this intended to be standard-conforming?

ANSWER:

Yes, this is intended to be standard-conforming.
An edit is supplied to correct the mistake in 12.4.3.2.

EDITS to 10-007r1:

[281:26] In 12.4.3.2 Interface block, paragraph 5,
  After "specific interface for an external procedure"
  change "or a dummy procedure"
  to     ", dummy procedure, or procedure pointer".
{Add procedure pointer for the list of things this can declare.}

[281:25-28] Same paragraph,
  After "interface body, the procedure is a dummy procedure"
  change "; otherwise"
  to ".  If the procedure has the POINTER attribute, it is a
      procedure pointer.  If it is not a dummy procedure or
      procedure pointer".
{Correct how we establish what it is.}

This makes that whole paragraph read:

  An interface body in a generic or specific interface block specifies
  the EXTERNAL attribute and an explicit specific interface for an
  external procedure, dummy procedure, or procedure pointer.  If the
  name of the declared procedure is that of a dummy argument in the
  subprogram containing the interface body, the procedure is a dummy
  procedure.  If the procedure has the POINTER attribute, it is a
  procedure pointer.  If it is not a dummy procedure or
  procedure pointer, it is an external procedure.

{Note careful wording to avoid saying that a dummy procedure is not a
 procedure pointer, since a dummy procedure pointer is indeed both a
 dummy procedure and a procedure pointer.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-136    m206  F08/0132 submitted - passed by J3 meeting
         15-187    m207  Passed by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0133
TITLE: Is unallocated actual associated with nonallocatable dummy OK?
KEYWORDS: OPTIONAL, ALLOCATABLE
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Does the following program conform to the 2008 standard?

program P
  integer, allocatable :: I(:)
  call s ( i )
contains
  subroutine S ( A )
    integer, intent(in), optional :: A(:)
    if ( present(a) ) then
      print *, 'A = ', a
    else
      print *, 'A is not present'
    end if
  end subroutine S
end program P

Subclause 6.7.1.3 says, concerning an unallocated allocatable variable,
"It shall not be supplied as an actual argument corresponding to a
nonallocatable dummy argument, except to certain intrinsic inquiry
functions."

On the other hand, subclause 12.5.2.12 says a dummy argument "is not
present if the dummy argument ... does not have the ALLOCATABLE ...
attribute, and corresponds to an actual argument that ... has the
ALLOCATABLE attribute and is not allocated...."

ANSWER:

The intent was that the program conforms, and prints "A is not present",
as specified by subclause 12.5.2.12.  Edits are provided to correct this
mistake.

EDITS to 10-007r1:

[10-007r1:129:8 6.7.1.3 p1, second item in bulleted list] Insert
"nonoptional" before "nonallocatable".

SUBMITTED BY: Van Snyder

HISTORY: 15-141    m206  F08/0133 submitted - passed by J3 meeting
         15-187    m207  Passed by J3 letter ballot 15-159
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0134
TITLE: <stat-variable> in an image control statement
KEYWORDS: stat=, image control statement
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Was it intended to allow <stat-variable> or <errmsg-variable> in an
image control statement to be coindexed? For example, was it intended
that this statement
    SYNC IMAGES(1, stat = is[2])
be allowed? It seems undesirable to involve image 2 when synchronizing
the executing image with image 1.

ANSWER:

No, it was not intended to allow the <stat-variable> or
<errmsg-variable> in an image control statement to be coindexed.

An edit is provided to correct this oversight.

EDITS to 10-007r1:

[190:5+] Add constraint
"C851a (R859) A <stat-variable> or <errmsg-variable> in a <sync-stat>
shall not be a coindexed object.

SUBMITTED BY: John Reid

HISTORY: 15-144    m206  F08/0134 submitted - passed by J3 meeting
         15-187    m207  Passed by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0135
TITLE: Vector subscripted actual makes VALUE dummy undefinable?
KEYWORDS: VALUE, definable, vector subscript
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

12.5.2.4p18 [295:3-4] says
  "If the actual argument is an array section having a vector
   subscript, the dummy argument is not definable and shall not have
   the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE
   attributes."

This would seem to be a strange requirement when the dummy argument
has the VALUE attribute (and so is not argument-associated with the
actual argument anyway).

Consider

  program P1
    real :: X(3)
    call S1 ( X ( [ 1, 3, 2 ] ) )
  contains
    subroutine S1 ( A )
      real, value :: A(:)
      A = 3
      print *, A
    end subroutine
  end program

and

  PROGRAM p2
    REAL :: x(3) = [ 10,20,30 ]
    OPEN(10,ASYNCHRONOUS='YES',FORM='UNFORMATTED')
    CALL s2( x( [ 1,2,2,1 ] ) )
  CONTAINS
    SUBROUTINE s2(a2)
      REAL,VALUE,ASYNCHRONOUS :: a2(:)
      READ(10,ASYNCHRONOUS='YES') a2
      PRINT *,'reading...'
      WAIT(10)
      PRINT *,a2
    END SUBROUTINE
  END PROGRAM

Are these two programs standard-conforming?  In particular, is the
assignment to A permitted in S1, and is the dummy argument a2
permitted to have the ASYNCHRONOUS attribute in s2.

ANSWER:

These two programs were intended to be standard-conforming.  Subclause
12.5.2.3 states that a VALUE dummy argument is associated with a
definable data object and not with the actual argument.  An edit is
supplied to correct this mistake.

EDITS to 10-007r1:

[295:3] 12.5.2.4 Ordinary dummy variables, p18, after applying the
        changes in F2008 Corrigendum 1, between "is nonelemental" and
        "and the actual argument", insert
          ", the dummy argument does not have the VALUE attribute,".
        This makes that whole sentence read
  "If the procedure is nonelemental, the dummy argument does not have
   the VALUE attribute, and the actual argument is an array section
   having a vector subscript, the dummy argument is not definable and
   shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or
   VOLATILE attributes."

SUBMITTED BY: Van Snyder

HISTORY: 15-148    m206  F08/0135 submitted - passed by J3 meeting
         15-187    m207  Passed as amended by J3 letter ballot 15-159
         N2080     m207  Passed as amended by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0136
TITLE: Argument correspondence with VALUE and ASYNCHRONOUS
KEYWORDS: VALUE, ASYNCHRONOUS, coindexed, contiguous
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider the following three programs and discussions:

program P1
  real, asynchronous :: X[*]
  call S1 ( X [ 1 ] )
contains
  subroutine S1 ( A )
    real, value, asynchronous :: A
    a = 3
  end subroutine S1
end program P1

Program P1 appears to violate C1238 which says
  "An actual argument that is a coindexed object with the ASYNCHRONOUS
   or VOLATILE attribute shall not correspond to a dummy argument that
   has either the ASYNCHRONOUS or VOLATILE attribute."
but the dummy argument is not associated with the actual argument so
it is unclear why that should be the case.

program P2
  real, asynchronous :: X(3)
  call S2A ( X )
contains
  subroutine S2A ( A )
    real, asynchronous :: A(:)
    call S2B ( A(1:3) )
  end subroutine S2A
  subroutine S2B ( A )
    real, value, asynchronous, contiguous :: A(:)
    a = 3
  end subroutine S2B
end program P2

This appears to violate C1239 which says
  "If an actual argument is a nonpointer array that has the
   ASYNCHRONOUS or VOLATILE attribute but is not simply contiguous
   (6.5.4), and the corresponding dummy argument has either the
   VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an
   assumed-shape array that does not have the CONTIGUOUS attribute."
but again, it is unclear why that should matter for a VALUE dummy
argument.

program P3
  real, target :: X(3)
  real, pointer, asynchronous :: Y(:)
  y => x
  call S3 ( y )
contains
  subroutine S3 ( A )
    real, value, asynchronous, contiguous :: A(:)
    a = 3
  end subroutine S3
end program P3

This program appears to violate C1240 which says
  "If an actual argument is an array pointer that has the ASYNCHRONOUS
   or VOLATILE attribute but does not have the CONTIGUOUS attribute,
   and the corresponding dummy argument has either the VOLATILE or
   ASYNCHRONOUS attribute, that dummy argument shall be an array
   pointer or an assumed-shape array that does not have the CONTIGUOUS
   attribute."
but it is unclear why this should matter for a VALUE dummy argument.

Are those programs intended to be standard-conforming?

ANSWER:

Yes, all those programs were intended to be standard-conforming.
There is no need for those constraints to apply to dummy arguments
with the VALUE attribute, because a VALUE dummy argument is not
associated with the actual argument but with an anonymous definable
data object.

Edits are supplied to correct the mistakes in the constraints.

EDITS to 10-007r1:

[295:6] 12.5.2.4 Ordinary dummy arguments, C1238,
  Between "VOLATILE attribute" and "."
  insert  ", unless the dummy argument has the VALUE attribute".

[295:9] Same subclause, C1239,
        After "ASYNCHRONOUS attribute"
        insert ", but does not have the VALUE attribute".

[295:13] Same subclause, C1240,
         After "ASYNCHRONOUS attribute"
         insert ", but does not have the VALUE attribute".

SUBMITTED BY: Van Snyder

HISTORY: 15-149    m206  F08/0136 submitted
         15-149r4  m206  Fix answer and typos - passed by J3 meeting
         15-187    m207  Passed by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0137
TITLE: Result of TRANSFER when MOLD is an array with element size zero
KEYWORDS: TRANSFER, zero-sized scalar
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider the following examples:

Example 1:
  CHARACTER(0),PARAMETER :: nothing1(100) = ''
  PRINT *,SIZE(TRANSFER(111014,nothing1))

Example 2:
   TYPE empty
   END TYPE
   ! When the physical representation of empty() has size zero;
   ! this is not required but does seem to be permitted.
   TYPE(empty),PARAMETER :: nothing2(1) = empty()
   PRINT *,SIZE(TRANSFER(111014,nothing2))

Example 3:
   TYPE nonempty
     REAL c(0)
   END TYPE
   TYPE(nonempty),PARAMETER :: nothing3(0) = nonempty(0.0)
   PRINT *,SIZE(TRANSFER(111014,nothing3))

According to Fortran 2008, 13.7.168, the result of TRANSFER in this
case is an array of rank one whose
  "size is as small as possible such that its physical representation
   is not shorter than that of SOURCE".
However, the size of a zero-length character is zero and the size of
the above derived types may be zero, no matter how many array elements
there are, so these examples do not seem to be well-defined.

Also consider the following examples, with nothing1 defined as in
example 1.

Example 4:
  CHARACTER(0) :: source1 = ''
  PRINT *,SIZE(TRANSFER(source1,nothing1))

Example 5:
  CHARACTER(999) :: source2(0) = REPEAT('!',999)
  PRINT *,SIZE(TRANSFER(source2,nothing1))

In these cases the physical representation of an element of MOLD has
size zero, but then so does the physical representation of the SOURCE
argument.  According to the quoted text, that would mean that TRANSFER
should return a zero-sized array, i.e. the examples will print zero.

Example 6:
  CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument.
  CHARACTER(999) :: source3(0) = REPEAT('!',999)
  PRINT *,SIZE(TRANSFER(source3,maybe_nothing))

Example 7:
  CHARACTER(*),INTENT(IN) :: maybe_nothing(:) ! A dummy argument.
  CHARACTER(999) :: source4(10) = REPEAT('!',999)
  PRINT *,SIZE(TRANSFER(source4,maybe_nothing))

In these examples, the physical representation of MOLD is not known at
compile time, but depends on the length of the dummy argument.  Using
the analysis above, example 6 would seem to be conforming (and print
zero), while example 7 would seem to be conforming if and only if the
length of maybe_nothing is nonzero at execution time.

Which of the examples are conforming?  If any of examples 1-3 are
conforming, what value is printed?

ANSWER:

Example 1 is not conforming, and if the derived types have size zero
in examples 2 and 3, those examples are also not conforming, as no
interpretation is established for them.  An edit is provided to
clarify that they are not valid.

Examples 4-6 are conforming, and the value zero is printed.

Example 7 is conforming if and only if the length of maybe_nothing is
not zero.  The same edit clarifies that the zero-length case is not
valid.

EDITS to 10-007r1:

[393:18] 13.7.168 TRANSFER, p3 Arguments, MOLD, append
  "If the storage size of SOURCE is greater than zero and MOLD is an
   array, a scalar with the type and type parameters of MOLD shall not
   have a storage size equal to zero.".
{It is ok for MOLD itself to have storage size zero, in the case where
 MOLD is a zero-sized array but the storage size of a scalar with its
 type and type parameters would be greater than zero.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-152    m206  F08/0137 submitted - passed by J3 meeting
         15-187    m207  Passed as amended by J3 letter ballot 15-159
         N2080     m207  Passed by WG5 ballot 9 N2061/62
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0138
TITLE: Type extension in submodules
KEYWORDS: submodules, deferred type-bound procedures
DEFECT TYPE: Clarification
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider the following code:

    module mod_a
      implicit none
      type, abstract :: t_a
       contains
         procedure(p_a), deferred :: p
      end type t_a
      abstract interface
         subroutine p_a(this, q)
           import :: t_a
           class(t_a), intent(inout) :: this
           class(*), intent(in) :: q
         end subroutine
      end interface
    end module mod_a

    submodule(mod_a) imp_p_a
      type, extends(t_a) :: t_imp
         real :: b
      contains
         procedure :: p => psub ! (A)
      end type t_imp
    contains
      subroutine psub(this, q)
        class(t_imp), intent(inout) :: this
        class(*), intent(in) :: q
        ... ! don't care
      end subroutine psub
    end submodule imp_p_a

Constraint C465 in 10-007r1 reads

"C465 (R448) The procedure-name shall be the name of an accessible
      module procedure or an external procedure that has an explicit
      interface."

Therefore it would appear that statement (A) above is not standard
conforming since PSUB is not the name of a module procedure.

Q1. Is this correct?

If so, extension of a derived type with a deferred type-bound
procedure cannot be done within the specification part of a submodule.

Q2. Was this intended?

ANSWER:

A1. No, this is not correct.  A module procedure is a procedure that
    is defined by a module subprogram (1.3.112.4).  A submodule
    program unit contains a module-subprogram-part (R1116), and this
    contains a (possibly-empty) sequence of module-subprogram's
    (R1107).  Therefore, PSUB is defined by a module subprogram and
    is therefore a module procedure.  Therefore, the statement that
    is commented "(A)" is standard-conforming.

A2. Moot.

EDITS to 10-007r1:

None.

SUBMITTED BY: R. Bader

HISTORY: 15-160    m207  F08/0138 Submitted
         15-160r1  m207  Revised
         15-160r2  m207  Revised example passed by J3 meeting
         N2093     m209  Passed as amended by J3 LB #35/WG5 ballot #11
                          [2091/92/93]
         N2102     m209  No edits in F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0139
TITLE: Is the name of an external procedure that has a binding label
       a local identifier?
KEYWORDS: binding label, local identifier
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider the program fragment containing the external subprograms:

  Subroutine s() Bind(C,Name='Hello')
      Print *,'Hello'
  End Subroutine
  Subroutine s() Bind(C,Name='World')
    Print *,'World'
  End Subroutine

This does not conform to Fortran 2003, and is not listed as an
extension in the Introduction to Fortran 2008, but the rules for
global names seem to indicate that this is now conforming.

Is this extension deliberate?

ANSWER:

Yes, this was a deliberate change to the Fortran standard.
An edit is provided to mention this in the Introduction.

EDITS to 10-007r1:

[xvi] Introduction, paragraph 2, bullet "Programs and procedures",
      append to paragraph
        "The name of an external procedure that has a binding label
         is a local identifier and not a global identifier.".

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-177    m207  F08/0139 submitted - passed by J3 meeting
         N2093     m209  Passed as amended by J3 LB #35/WG5 ballot #11
                          [2091/92/93]
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0140
TITLE: Assign to deferred-length coindexed character variable
KEYWORDS: Cobounds, type declaration
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Q1. Consider the program:

  Program p1
    Type t
      Character(:), Allocatable :: C
    End Type
    Type(t) x[*]
    Allocate ( Character(42) :: x%c )
    Sync All
    If (This_Image()==1) x[2]%c = 'stuff'
  End Program

Is the assignment permitted?

Q2. Consider

  Program p2
    Type t
      Character(:), Pointer :: C
    End Type
    Type(t) x[*]
    Allocate ( Character(42) :: x%c )
    Sync All
    If (This_Image()==1) x[2]%c = 'stuff'
  End Program

Is the assignment permitted?

ANSWER:

A1. This is not permitted, as it violates the requirement in 7.2.1.2
    Intrinsic assignment statement, paragraph 2, which states that if
    the variable (in an intrinsic assignment statement) is coindexed,
    its deferred length type parameters shall be the same as the
    corresponding type parameters of the expression.

    There is a grammatical error in this requirement; an edit is
    supplied to correct the grammatical error.

A2. This was intended to be permitted, but was inadvertently caught in
    the prohibition that was intended to apply only to allocatable
    variables.  An edit is supplied to correct this error.

EDITS to 10-007r1:

[153:25] 7.2.1.2p2, after "coindexed object,", delete "the variable",
[153:26] before "shall not be" insert "the variable",
[153:27] before "shall not have" insert "the variable",
[153:28] after "deferred length type parameter" insert "of the variable"
making the whole paragraph read

  "If <variable> is a coindexed object,
     - the variable shall not be polymorphic,
     - the variable shall not have an allocatable ultimate component,
       and
     - each deferred length type parameter of the variable shall have
       the same value as the corresponding type parameter of <expr>.".

SUBMITTED BY: Van Snyder

HISTORY: 15-161    m207  F08/0140 submitted
         15-161r1  m207  Revised question and answers
         15-161r2  m207  Passed by J3 meeting
         N2093     m209  Passed as amended by J3 LB #35/WG5 ballot #11
                          [2091/92/93]
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0141
TITLE: Can a statement function have a variable-length PDT result?
KEYWORDS: Statement function, parameterized derived type
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider

    MODULE m207c006
      TYPE string(n)
        INTEGER,LEN :: n
        CHARACTER(n) :: v
      END TYPE
    END MODULE
    PROGRAM test
      USE m207c006
      CALL s(3)
      CALL s(7)
    CONTAINS
      SUBROUTINE s(n)
        TYPE(string(n)) sf
        TYPE(string(n)) var(3)
        sf(nn) = var(nn)
        var(1) = string(n)('123456789')
        var(2) = string(n)('abcdefgh')
        PRINT *,sf(1),sf(2)
      END SUBROUTINE
    END PROGRAM

If this is conforming, it would appear that the output ought to be
  123abc
  1234567abcdefg

However, for the following reasons, perhaps this is not intended to be
conforming.

(1) A statement function of type character is required to have a
    constant length type parameter.  There is no such requirement on a
    statement function of parameterized derived type.  This seems
    inconsistent, since one can wrap a variable-length character
    in a parameterized derived type.

(2) A statement function is not permitted to invoke a nonintrinsic
    function that requires an explicit interface (and having a PDT
    result requires an explicit interface), nor is it permitted to
    contain a structure constructor.  This would seem to render such a
    statement function almost completely useless, since all it can do
    is to choose between PDT constants or variables, or use an
    intrinsic function such as TRANSFER to construct the result.

(3) Statement functions were declared to be obsolescent long before
    the addition of parameterized derived types to the standard.  It
    has been general policy not to "improve" obsolescent features.
    This would seem to indicate that statement functions were not
    intended to be capable of having parameterized derived type in the
    first place.

Q1. Are statement functions of parameterized derived type intended to
    be conforming?

Q2. If so, are statement functions of parameterized derived type with
    nonconstant length type parameters intended to be conforming?

Q3. If so, is the expected output from the example program above as
    described?

ANSWER:

A1. No, statement functions were not intended to be permitted to be of
    parameterized derived type.  The exception for statement functions
    from the explicit interface requirements was overlooked.  An edit
    is provided to prohibit these.

A2, A3.  Moot.

EDITS to 10-007r1:

[24:11+] 1.6.2 Fortran 2003 compatibility, insert new paragraph
  "Fortran 2003 permitted a statement function to be of parameterized
   derived type; this part of ISO/IEC 1539-1 does not permit that."
{Previous corrigenda have already inserted incompatibility
 paragraphs.}

[311:34+] 12.6.4 Statement function, after C1275, insert constraint
  "C1275a A statement function shall not be of a parameterized derived
          type."

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-179    m207  F08/0141 submitted
         15-179r1  m207  Revised edits - passed by J3 meeting
         N2093     m209  Passed as amended by J3 LB #35/WG5 ballot #11
                          [2091/92/93]
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0142
TITLE: Is useless module extension permitted?
KEYWORDS: SUBMODULE
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

If a module declares no separate module procedure, it cannot have a
useful submodule as such a submodule has nothing to provide.  Its
module procedures and variables cannot be referenced by any program.

Should useless extension have been prohibited?

ANSWER:

Yes.  Permitting such extension would require the implementation to
export the private details of a module merely for the purpose of
compiling a useless submodule.

An edit is provided to require the ancestor of a submodule to have
declared a separate module procedure.

EDITS to 10-007r1:

[275:18] 11.2.3 Submodules, C1113,
         After "shall be the name of a nonintrinsic module"
         insert "that declares a separate module procedure".

SUBMITTED BY: Daniel Chen

HISTORY: 15-209    m207  F08/0142 submitted - passed  by J3 meeting
         N2093     m209  Passed by J3 LB #35/WG5 ballot #11 [2091/92/93]
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0143
TITLE: May a pure procedure have an INTENT(OUT) polymorphic component?
KEYWORDS: PURE, INTENT(OUT), polymorphic
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider:

  Type t
    Class(*),Allocatable :: c
  End Type
  ...
  Pure Subroutine zap(x)
    Type(t),Intent(Out) :: x
    x%c = 'I wonder if that invoked an impure procedure?'
  End Subroutine

Is this program standard-conforming?

ANSWER:

No, this is not standard-conforming.

Corrigendum 1 of Fortran 2008 added the constraint
  "C1284a A statement that might result in the deallocation of a
          polymorphic entity is not permitted in a pure procedure."

The type declaration statement with INTENT(OUT) causes the
deallocation of the polymorphic component X%C, and is therefore not
allowed.

However, this is difficult to understand, so a clarifying edit is
provided.

EDITS to 10-007r1:

In Clause 12.7, para, 2, in 10-007r1 [312:23+], in the constraint added
by Corrigendum 1,
  "C1278a An INTENT (OUT) dummy argument of a pure procedure shall not
          be polymorphic."

after the word "polymorphic"
insert "or have a polymorphic allocatable ultimate component".

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-211    m207  F08/0143 submitted - passed by J3 meeting
         N2093     m209  Passed as amended by J3 LB #35/WG5 ballot #11
                          [2091/92/93]
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0144
TITLE: Is ADVANCE= allowed during execution of DO CONCURRENT?
KEYWORDS: nonadvancing I/O, DO CONCURRENT
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider

  program P
    integer :: I
    do concurrent ( I = 1:10 )
      write ( *, '(I5)', advance='NO' ) I
    end do
    write ( *, * )
  end program P

Q1. Is this conforming and if so, what output is produced?

  program Q
    integer :: I
    logical :: L(10) = .FALSE.
    real :: X(10) = 0
    do concurrent ( I = 1:10 )
      if ( mod(i,2) == 0 ) then
        read ( *, '(g15.6)', advance='no' ) X(I)
      else
        read ( *, '(l3)', advance='no' ) L(I)
      end if
    end do
    print *, X, L
  end program

Q2. Is this conforming and what kind of output would be expected?

ANSWER:

No, these programs are not conforming as no interpretation is
established for them.

It was intended that the ADVANCE= specifier not be permitted within a
DO CONCURRENT construct.

An edit is provided to address this oversight.

EDITS to 10-007r1:

[10-007r1:178:16+ 8.1.6.7p1] after the fourth bullet point, add
new bullet point:

"  o A DO CONCURRENT construct shall not contain an input/output
     statement that has an ADVANCE= specifier."

SUBMITTED BY: Van Snyder

HISTORY: 15-213    m207  F08/0144 submitted
         15-213r1  m207  Option 2 selected, edit revised - passed by
                          J3 meeting
         N2093     m209  Passed as amended by J3 LB #35/WG5 ballot #11
                          [2091/92/93]
         N2102     m209  In F2008 Corrigendum 4 as amended N2094/N2097

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

NUMBER: F08/0145
TITLE: Can initial-data-target be coindexed?
KEYWORDS: initialization, pointers, coarrays
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

In pointer assignment, the standard is quite clear that data-target
cannot be coindexed:

C725 (R737) A data-target shall not be a coindexed object.

And there are a couple of notes related to this:

NOTE 7.45
A data pointer and its target are always on the same image. A coarray
may be of a derived type with pointer or allocatable subcomponents. For
example, if PTR is a pointer component, Z[P]%PTR is a reference to the
target of component PTR of Z on image P. This target is on image P and
its association with Z[P]%PTR must have been established by the
execution of an ALLOCATE statement or a pointer assignment on image P.

NOTE 7.46
A pointer assignment statement is not permitted to involve a coindexed
pointer or target, see C723 and C725. This prevents a pointer
assignment statement from associating a pointer with a target on
another image. If such an association would otherwise be implied, the
association status of the pointer becomes undefined. For example, a
derived-type intrinsic assignment where the variable and expr are on
different images and the variable has an ultimate pointer component.

Fortran 2008 added the ability to specify an initial-data-target in
pointer initialization:

R505 initialization is = constant-expr
                    or => null-init
                    or => initial-data-target
R506 null-init      is function-reference

C510 (R503) If => appears in initialization, the entity shall have the
POINTER attribute. If = appears in initialization, the entity shall not
have the POINTER attribute.

C511 (R503) If initial-data-target appears, object-name shall be
data-pointer-initialization compatible with it (4.5.4.6).

Initial-data-target is defined in 4.5.4.6 and the only relevant
constraint for it is:

C461 (R443) The designator shall designate a nonallocatable variable
that has the TARGET and SAVE attributes and does not have a vector
subscript. Every subscript, section subscript, substring starting
point, and substring ending point in designator shall be a constant
expression.

The definition of "data-pointer-initialization compatible" is:

"A pointer variable or component is data-pointer-initialization
compatible with a target if the pointer is type compatible with the
target, they have the same rank, all nondeferred type parameters of the
pointer have the same values as the corresponding type parameters of
the target, and the target is contiguous if the pointer has the
CONTIGUOUS attribute."

Given this, is initializing a pointer to a coindexed object permitted?

For example:

program test
integer, save, target :: C[*]
integer, pointer :: P => C[3] ! Permitted?
end

While ordinary pointer assignment to a coindexed object is prohibited
by C725, there is no corresponding constraint prohibiting such
association by way of data pointer initialization.

Note that 16.5.2.5p1(2) says that pointer-assigning to a target on a
different image causes the pointer to become undefined. Since the
initialization occurs on all images, and it's not possible to restrict
the target to only the same image, the effect would be to make a
program that does this nonconforming.

ANSWER:

No, this was not intended to be permitted. A clarifying edit is
provided.

EDITS to 10-007r1:

[70:3] 4.5.4.6

In the first sentence of C461, insert ", noncoindexed" after
"nonallocatable" so that the sentence reads:

C461 (R443) The designator shall designate a nonallocatable,
noncoindexed variable that has the TARGET and SAVE attributes and
does not have a vector subscript.

SUBMITTED BY: Steve Lionel

HISTORY: 15-216    m208  F08/0145 submitted - passed by J3 meeting
         16-103    m209  Passed by J3 letter ballot #34 16-101
         N2087     m209  Passed by WG5 ballot #10 N2085/86
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0147
TITLE: Is generic resolution of elemental assignment done at runtime?
KEYWORDS: Type-bound defined assignment, Allocatable
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider

  Module da_module
    Type t
      Real c
    End Type
    Interface Assignment(=)
      Module Procedure edasgn
    End Interface
  Contains
    Elemental Subroutine edasgn(a,b)
      Type(t),Intent(Out) :: a
      Type(t),Intent(In) :: b
      a%c = -b%c
    End Subroutine
  End Module
  Program edatest
    Call test(10,10,13)
  Contains
    Subroutine test(n,n2,m)
      Use da_module
      Type(t) :: x(n),z(m)
      Type(t),Allocatable :: y(:)
      x%c = [ (i,i=1,n) ]
      z%c = [ (i,i=1,m) ]
      Allocate(y(n2),Source=t(0))
      y = x                        ! A
      Print 1,y
    1 Format(*(1X,F0.1,:))
      y = z                        ! B
      Print 1,y
    End Subroutine
  End Program

According to 7.2.1.2 Intrinsic assignment statement, an assignment
statement is an intrinsic assignment statement if (and only if) it
is not a defined assignment statement.  According to 7.2.1.4 Defined
assignment statement, a defined assignment statement needs to have a
subroutine that defines the assignment "x1 = x2".  For elemental
subroutines (item (5)(b)), that is true only if
  "x1 and x2 are conformable"
which when x1 and x2 are both arrays, means "has the same shape".
For the example above, in the assignment marked (A), x and y will be
conformable (as both n and n2 are equal to 10), making that a defined
assignment, thus the PRINT statement after it would print
 -1.0 -2.0 -3.0 -4.0 -5.0 -6.0 -7.0 -8.0 -9.0 -10.0
while in the assignment statement marked (B), y and z will not be
conformable (n2 being 10 and m being 13), making it an intrinsic
assignment.  In this case, because Y is allocatable it will be
reallocated, and so the output from the second PRINT statement would
be
 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0

However, this would seem to violate the fundamental principle that
generic references are resolvable at compile time.  It would also
seem to be nearly useless since if the variable is not allocatable
the shapes are required to conform anyway.

Is this feature intended to work like this?

ANSWER:

No, this was a mistake.  Edits are provided to remove the runtime
generic resolution.

After the edits:
  1) The assignment A is defined assignment and is conforming (from 
     first edit).

  2) The assignment B is defined assignment but is not standard conforming,
     since the shapes differ (from second edit).
 
  3) For a defined assignment statement, auto-reallocation of 
     allocatables does not occur, as that is only done by an intrinsic 
     assignment statement.

EDITS to 10-007r1:

[24:11+] 1.6.2 Fortran 2003 compatibility, insert new incompatibility
  "Fortran 2003 interpreted assignment to an allocatable variable
   from a nonconformable array as intrinsic assignment, even when an
   elemental defined assignment was in scope; this part of ISO/IEC
   1539 does not permit assignment from a nonconformable array in
   this context.".
{The unintended extension is weird and violates our own principles,
 but is not in itself contradictory or ambiguous so this is an
 incompatibility.}

[157:14] 7.2.1.4 Defined assignment statement, p2, item (5)(b),
         Change "$x_1$ and $x_2$ are conformable"
         to "$x_2$ is scalar or has the same rank as $x_1$".
{$x_1$ is TeX for italics x subscript 1.}

[157:16] Same subclause, p3, append new sentence
  "If the subroutine is elemental, $x_2$ shall have the same shape as
   $x_1$."
{Retain conformability as a normal requirement instead of as a
 condition.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-219    m208  F08/0147 submitted - passed by J3 meeting
         16-103    m209  Passed as amended by J3 letter ballot #34 16-101
         N2087     m209  Passed as amended by WG5 ballot #10 N2085/86
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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

NUMBER: F08/0148
TITLE: Pointer subobject in structure constructor in pure procedure
KEYWORDS: pointer subobject, structure constructor, pure procedure
DEFECT TYPE: Erratum
STATUS: In F2008 Corrigendum 4

QUESTION:

Consider the module

program P

  type :: T1
    integer, pointer :: P1
  end type T1

  type :: T2
    type(t1) :: P2
  end type T2

  type(t1), target :: V1

  allocate ( V1%p1, source = 42 )

contains

  pure subroutine S ( )
    type(t2) :: A
  1 a = t2(v1)
    a%p2%p1 = a%p2%p1 + 1
  end subroutine S

end program P

Item (3) in the list in constraint C1283 in subclause 12.7 prohibits
an object that is accessed by host or use association (and other
categories) to be the <expr> in a structure constructor that
corresponds to a component that has the POINTER attribute.  It is
silent concerning type constructors for types that have potential
subobject components with the POINTER attribute.

Is the statement labeled 1 permitted?  If so, was that intended?

ANSWER:

The statement labeled 1 was inadvertently allowed because V1
corresponds to a component of the structure constructor for type T2
that does not have the POINTER attribute.

An edit is provided to correct this mistake.

EDITS to 10-007r1:

[312:35 12.7p2 C1283(3)] Replace this list item by
  "(3) as the <expr> corresponding to a component in a
       <structure-constructor> if the component has the POINTER
       attribute or has a pointer component at any level of
       component selection,"

SUBMITTED BY: Van Snyder

HISTORY: 15-249    m208  F08/0148 submitted
         15-249r1  m208  fix typos - passed J3 meeting
         16-103    m209  Passed as amended by J3 letter ballot #34 16-101
         N2087     m209  Passed by WG5 ballot #10 N2085/86
         N2102     m209  In F2008 Corrigendum 4 N2094/N2097

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