(j3.2006) Interp letter ballot #25

Van Snyder Van.Snyder
Wed May 9 20:12:33 EDT 2012

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.

43 Fortran interpretations are currently "Passed by J3 meeting" after
J3 meeting #197.  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/0017   Dummy procedure pointers and PRESENT
-Y-  ---  F03/0018   Multiple identical specific procedures in
                      type-bound generic interfaces
-Y-  ---  F03/0019   Multiple identical specific procedures in
                      generic interface blocks
-Y-  ---  F03/0021   What kind of token is a stop code?
-Y-  ---  F03/0046   Unlimited polymorphic pointers in
                      common blocks
-Y-  ---  F03/0053   The BIND attribute for C_PTR and C_FUNPTR
-Y-  ---  F03/0065   Relational equivalence
---  -N-  F03/0084   IEEE_SET_ROUNDING_MODE in a subroutine
            One of the reasons given for not needing to add interval
            arithmetic to the work plan for 2003 was that the effect
            could be provided using the IEEE facilities.  If one writes
              V%LOW_BOUND = X * Y
              V%HIGH_BOUND = X * Y
            perhaps naively hoping that the processor will actually
            round in the specified ways and produce different results
            for the low and high bounds, it would be a nasty surprise
            to find that in fact the values are always identical.
-Y-  ---  F03/0096   Can a read statement change the unit value?
---  -N-  F03/0103   Restrictions on dummy arguments not present for
                      polymorphic type or parameterized derived type
            I agree that the answer correctly handles the case of
            length type parameters (Q2), but it appears not to have
            addressed the question of polymorphism (Q1).
-Y-  ---  F03/0116   indistinguishable specifics for a generic
                      interface with use association
-Y-  ---  F03/0118   Are lower bounds of assumed-shape arrays assumed?
-Y-  ---  F03/0120   When are parameterized sequence types the same
---  -N-  F03/0121   Precise FP semantics of the REAL intrinsic

            The answer to this interpretation is inconsistent with
            13.7.1p2, including as amended by F08/0008: "A program shall
            not invoke an intrinsic procedure under circumstances where a
            value to be assigned to a subroutine argument or returned as a
            function result is not representable by objects of the
            specified type and type parameters."  This interpretation
            permits REAL(0.1d0,kind(1.0e0)) to return a value that is not
            representable as default real.  The meaning of "representable
            by objects of the specified type and type parameters" is taken
            from 4.1.1p2 ("A type has ... a set of valid values"), 4.1.2p1
            ("For each type, there is a set of valid values"), and 4.2p1
            ("A type might be parameterized.  In this case, the set of
            values... depend on the values of the parameters").  If the
            result is not a member of the "set of valid values" (which
            depends upon "values of the parameters"), the function cannot
            be invoked.  The caveat in that "mathematically
            equivalent expressions of numeric type may produce different
            computational results" does not include permission to produce
            a value that is not a member of the set of valid values for
            the type and type parameters of that result.

            One of the reasons advanced in discussion for the provided
            answer (but not in the text of the final interpretation) was
            that it would intolerably slow down programs if the REAL
            intrinsic function were to operate as most readers understand
            the description in subclause 13.7.138, taken in the light of
            13.7.1p2 (as amended by F08/0008), 4.1.1p2, 4.1.2p1 and 4.2p1,
            until they are surprised by the present answer.  This is
            nonsense.  The only reason ever to invoke the REAL intrinsic
            function with a real argument is to provide a result value of
            the specified kind.  Appearance of an invocation of the REAL
            intrinsic function with a REAL argument is rare (in my 1/3
            million line program, it appears twice), and ought not to
            cause a measureable performance degradation in a real program
            (i.e., one that is a not carefully contrived SPEC benchmark),
            even if the semantics are as one would expect from reading the
            description of the REAL intrinsic function, taken in the light
            of 13.7.1p2 (as amended by F08/0008), 4.1.1p2, 4.2.1p1 and
            4.2p1.  If it ever is an issue for performance, processors can
            provide an option that enables an extension that invalidates
            the requirements of 13.7.1p2 (as amended by F08/0008),
            4.1.1p2, 4.2.1p1 and 4.2p1, at least to the extent they would
            apply to the REAL intrinsic function.

-Y-  ---  F08/0004   Is TARGET argument of ASSOCIATED a pointer or
                      nonpointer dummy?
-Y-  ---  F08/0008   IEEE exceptions for intrinsic functions
-Y-  ---  F08/0031   PURE INTENT(OUT) finalization
-Y-  ---  F08/0032   PURE FUNCTION result finalization
-Y-  ---  F08/0038   Are pointless restrictions on DIM arguments
-Y-  ---  F08/0040   MOVE_ALLOC for coarrays
-Y-  ---  F08/0042   SOURCE= questions
-Y-  ---  F08/0043   Executing a type-bound procedure on a coindexed
-Y-  ---  F08/0048   Sequence association for coarrays
-Y-  ---  F08/0054   Requirements for needing an explicit interface
-Y-  ---  F08/0055   G editing for reals
-Y-  ---  F08/0056   Non-polymorphic ALLOCATE with polymorphic SOURCE=
-C-  ---  F08/0057   Interoperability with empty types
            I would put the new constraint before C1501
-C-  ---  F08/0058   ENTRY point RESULT variable
            There's nothing wrong with the interpretation, or the answer
            or edits, but it does raise the question whether the RESULT
            name of an entry statement is allowed to be the same as a
            dummmy argument of the function statement, or an earlier entry
            statement.  This is probably a question for a different
-C-  ---  F08/0059   Auto-targetting requirements
            Delete "and" from the edit for [295:16-17], or replace "with"
            by "that has"
-Y-  ---  F08/0060   Procedure pointer assignment with an EXTERNAL target
-C-  ---  F08/0061   Description of the CONTIGUOUS attribute misworded?
            WG5/J3 ought to decide whether to include the suggested
            addition to a future standard in 008.
-Y-  ---  F08/0062   Mixing default initialization with DATA
-Y-  ---  F08/0063   G editing to a narrow output field
-Y-  ---  F08/0065   Should certain procedures in intrinsic modules be
-C-  ---  F08/0066   Are certain expressions with pointer initialization
            ", TRANSFER" in the edit for [152:4] should be ", or TRANSFER"
            Edit for [152:7+] should be at [152:6+]
-C-  ---  F08/0067   Passing arrays of extended type objects
            Edit would be simpler as "insert 'a polymorphic assumed-size
            array or' after 'is'" at [293:4]
---  -N-  F08/0068   Pointer association and extended type arrays
            "declared type part of that target" is ambiguous.  "Declared
            type" of what?  (Also see F08/0069.)  The target or the
            pointer?  Does "part" include the possibility of a component
            having the same declared type (whatever that means)?  Although
            substantially more wordy, needs to specify that the pointer
            becomes associated with the actual argument if the dynamic
            type of the actual argument is the same as the declared type
            of the pointer, or with the ancestor component of the actual
            argument that has the same type as the declared type of the
            pointer.  If "ancestor component" were reflexive, the
            circumlocution would not be needed.
-Y-  ---  F08/0069   Which part of an effective argument becomes
-C-  ---  F08/0070   Finalization of INTENT(OUT) arguments
            Edit should say where it applies, instead of referring to "the
            quoted text" in the question (of which there are two), since
            the question will not appear in a corrigendum.  Specifying the
            location of the correction is a bit complicated since it's a
            correction to a correction in a corrigendum.  Also, the second
            quoted text [] says "only the part of the effective
            argument..." when it ought to say "only the ancestor
            component...."  Maybe that's the subject for a different
-C-  ---  F08/0071   Vector subscript target
            If the additional suggested edits are not put forward for
            inclusion in a corrigendum, WG5/J3 ought to decide whether to
            include them in 008.
-Y-  ---  F08/0072   Final subroutines with corank
-Y-  ---  F08/0073   Polymorphic auto-targetting

More information about the J3 mailing list