(j3.2006) J3 Fortran interp letter ballot #22 - due 19-Nov-2010

Jim Xia jimxia
Fri Nov 19 09:07:11 EST 2010


To:        J3 Members
From:      Stan Whitlock
Subject:   J3 Fortran interp letter ballot #22 - due 19-Nov-2010
Date: 2010 October 14

Enclosed in the next letter ballot on Fortran interpretations.

The rules by which we operate say:

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

    o   Between J3 meetings the chair of /interp sends a J3 letter
        ballot to J3 to approve interp answers that have been "passed
        by J3 meeting".  The letter ballot runs for 30 days.  Not
        voting on three of four consecutive J3 letter ballots is
        grounds to terminate J3 membership.  An interp answer passes
        by a 2/3rds vote;  a no vote must be accompanied by an
        explanation of the changes necessary to change the member's
        vote to yes.

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

22 Fortran interpretations are currently "Passed by J3 meeting" after
J3 meeting #193.  This is the letter ballot phase to go from "Passed
by J3 meeting" to "Passed by J3 letter ballot".

The following Fortran interpretations are being balloted:

Yes  No   Number     Title

-Y-  ---  F03/0030   IEEE divide by zero
-Y-  ---  F03/0048   Control edit descriptors in UDDTIO
-Y-  ---  F03/0085   Finalizing targets of pointer or allocatable
                      actual arguments
-Y-  ---  F03/0091   Array components cannot depend on length type
-Y-  ---  F03/0096   Can a read statement change the unit value?
-Y-  ---  F03/0105   SIZE= specifier and UDDTIO
-Y-  ---  F03/0110   Error in field width for special cases of signed
                      INFINITY output
-Y-  ---  F03/0121   Precise FP semantics of the REAL intrinsic
-Y-  ---  F03/0123   Implicit typing in derived types
-Y-  ---  F03/0124   definition is poorly defined
-Y-  ---  F03/0128   Subobjects in namelist output
-Y-  ---  F08/0006   generic resolution with banned argument
-Y-  ---  F08/0040   MOVE_ALLOC for coarrays
---  -N-  F08/0041   Segment ordering rules
-Y-  ---  F08/0042   SOURCE= questions
-Y-  ---  F08/0043   Executing a type-bound procedure on a coindexed
-Y-  ---  F08/0044   Resolving the type of a coarray or coindexed object
---  -N-  F08/0045   constraints on entities of type LOCK_TYPE
-Y-  ---  F08/0046   VALUE attribute restrictions
-Y-  ---  F08/0047   public generic with same name as private type
---  -N-  F08/0048   Sequence association for coarrays
-Y-  ---  F08-0049   ELEMENTAL functions with nonconstant type parameters

Comments on F08/0041
  The first example should be fixed to have t2 contains a pointer 
component of type
  t1.  The second example is perfectly legal.  Seems we need to rework on 
this interp.
Comments on F08/0045
        The edits makes it illegal to specify LOCK_TYPE as <type-spec> if 
the coarray itself
        is of LOCK_TYPE.
        For example, type(lock_type), allocatable :: locks[*]
        the edits make the following allocate statement illegal
        ALLOCATE (LOCK_TYPE: locks[*])

Comments on F08/0048
  I believe this restriction might be a bit surprising to users who 
  use sequence associations.  Also there isn't an apparent technical 
  in support this.

Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20101119/6c693883/attachment.htm>

More information about the J3 mailing list