J3/15-121 To: J3 Members From: Stan Whitlock Subject: Results of the J3 Fortran interp letter ballot #32 Date: 2015 February 09 Here are the results of J3 letter ballot #32 on Fortran interpretations that officially closed 9-Jan-2015. The ballot is in J3 paper 14-279 for meeting #205. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 / interp 105 110 115 116 117 118 119 120 121 122 123 124 result of LB #32 C Y Y Y Y Y C C C Y Y Y Daniel Chen Y Y Y Y Y Y Y Y Y Y Y Y Malcolm Cohen C C C C Robert Corbett Y Y Y Y Y Y Y Y Y Y N Y Bill Long Y N Y Y Y Y Y Y C Y C C Nick Maclaren C C Toon Moene Y Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y Y Y C Y Y Y N Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The comments for each interp are separated by a line of "*"s. The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" fail. The edited interps in their final form are attached and will appear in the next version 006. /Stan ************************************************************************ F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? Nick Maclaren's comment on F08/0105: The answer might be clearer if it added something like the following "Arguments with the VALUE and ASYNCHRONOUS attributes can be used for asynchronous transfers that both start and complete during that procedure call." Malcolm Cohen commented on Nick's comment: I don't think I'd add a whole new sentence, but perhaps modify the last sentence of p2 of the answer to read: 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. Result for F08/0105: /INTERP agrees with Malcolm's comment and will add the phrase "that both start and complete within that procedure call" to the last sentence of p2 of the answer so it read: 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. F08/0105 passed as amended by J3 letter ballot. F08/0110 Interdependence of specifier values in input/output statements Bill Long's No vote on F08/0110: I agree with the intent of the answer, but I think the edits say things we don't intend. In particular, "affected by [the] data transfer" is too broad. In the [243:3-5] edit we are saying that the value of the SIZE= specifier cannot "be affected by data transfer caused by that statement". This is certainly not true. The data transfer *determines* the value. The [243:6-7] edit implies that the statement read (*,*) I, A(I) is not conforming, since the denotation of A(I) depends on the value of I which certainly is "affected by the data transfer". Yet this sort of thing appears all over in existing codes. Malcolm Cohen commented on Bill's No vote on F08/0110: Bill Long writes: >For F08/0110: >------------- > >I agree with the intent of the answer, but I think the edits say >things we don't intend. In particular, "affected by [the] data >transfer" is too broad. > >In the [243:3-5] edit we are saying that the value of the SIZE= >specifier cannot "be affected by data transfer caused by that >statement". This is certainly not true. The data transfer >*determines* the value. It is not affected by the data transfer, it is affected by "what the data is". That is a horse of a different colour. The data transfer is the transfer of the data, which comes down to the definition of items in the input-list or (for an internal output statement) the definition of characters in the internal file. That is, the input (or output) data determines both the "data transfer" and the SIZE= value. It is not the actual transferring part that determines the SIZE= value. The "data transfer" is a subset of item (6) in 9.6.4.1p2, whereas setting SIZE= is item (9). I guess we could replace "data transfer" by "definition of variables by the transfer of the data", but that seems rather excessively verbose (ironic given your comment on another interp!). >The [243:6-7] edit implies that the statement > > read (*,*) I, A(I) > >is not conforming, since the denotation of A(I) depends on the >value of I which certainly is "affected by the data transfer". Yet >this sort of thing appears all over in existing codes. That edit DOES NOT SAY THAT. It says "The denotation of a variable that appears in a specifier ... shall not be affected...". An is not a specifier. That is, this will affect things like (the already invalid): read (*,*,iostat=i(n)) n Result for F08/0110: /INTERP does not agree with Bill's comments. F08/0110 passed by J3 letter ballot. F08/0115 ASYNCHRONOUS and argument passing Result for F08/0115: All Yes votes, no Comments, and no No votes. F08/0115 passed by J3 letter ballot. F08/0116 Interoperable procedures Result for F08/0116: All Yes votes, no Comments, and no No votes. F08/0116 passed by J3 letter ballot. F08/0117 TARGET and coindexed arguments Result for F08/0117: All Yes votes, no Comments, and no No votes. F08/0117 passed by J3 letter ballot. F08/0118 Subobject of variable in variable definition context Result for F08/0118: All Yes votes, no Comments, and no No votes. F08/0118 passed by J3 letter ballot. F08/0119 Branching to END BLOCK and END CRITICAL Van Snyder's yes vote with Comment on F08/0119: The second constraint proposed for a future revision, C847b, refers to the "range of the corresponding ." This was deleted by 14-243r2. Result for F08/0119: As remarked by Van, the "future revision" suggested insertion of constraint C847b will be removed. F08/0119 passed as amended by J3 letter ballot. F08/0120 Is the name of a procedure pointer a local identifier? Nick Maclaren commented on F08/0120: In the answer, "emend" => "amend". Result for F08/0120: The correction suggested by Nick will be made. F08/0120 passed as amended by J3 letter ballot. F08/0121 Add to introduction defined operations in specification exprs Bill Long's yes vote with Comment on F08/0121: The edit says more than is actually true. Not any is allowed in a specification expression. This could be fixed by changing the edit to "A defined by a specification function may be used in a specification expression." Malcolm Cohen commented on Bill's yes vote with comment on F08/0121: >For F08/0121: >------------- > >The edit says more than is actually true. Not any >is allowed in a specification expression. This could be fixed by >changing the edit to "A defined by a >specification function may be used in a specification expression." That would be a broken edit, since a is not EVER defined by a specification function. It is defined by an INTERFACE block or a GENERIC statement. There is a whole pile of extra rules that need to be followed (data type considerations, shape conformance, ...). Being resolved to a specification function is merely one of them. However, the edit should be using "can" (capability) not "may" (permission). That avoids giving the impression that the Introduction is providing normative requirements (something it is not allowed to do!). Result for F08/0121: /INTERP disagrees with Bill's comments. The correction suggested by Malcolm will be made. F08/0121 passed as amended by J3 letter ballot. F08/0122 Types with coarray components Result for F08/0122: All Yes votes, no Comments, and no No votes. F08/0122 passed by J3 letter ballot. F08/0123 SPACING intrinsic Robert Corbett's No vote on F08/0123: The results of applying the intrinsic functions SPACING and RRSPACING to subnormal values were the subject of interpretation F03/0055. Interpretation F03/0055 included edits that were incorporated in the Fortran 2008 standard. The proposed revised specification for the intrinsic function SPACING and the existing text are equivalent if the value of e\sub{min} is chosen properly for the KIND of real value. The text that F03/0055 added assumes that the value of e\sub{min} for a processor that supports subnormal numbers is the exponent of the smallest positive representable number. The Fortran 2008 standard does not spell out how the value of e\sub{min} is to be chosen, which must be addressed if the results of the intrinsic function SPACING are to be fully specified. If a different value of e\sub{min} is chosen, the result of SPACING for the value 0.0 becomes problematic. For example, if the value of e\sub{min} is chosen to be -126 for IEEE single-precision, the value of SPACING(0.0) will be 1.1754944E-38, while the value of SPACING(X) for a nonzero subnormal value will be 1.4012985E-45. SPACING(0.0) should not be greater than SPACING(X). Malcolm Cohen commented on Robert's No vote on F08/0123: Robert Corbett writes: >--------------------------------------------------------------- >F08/0123 N > >The results of applying the intrinsic functions SPACING and RRSPACING >to subnormal values were the subject of interpretation F03/0055. A >copy of that interpretation appears below. Interpretation F03/0055 >included edits that were incorporated in the Fortran 2008 standard. However that interp is not about the same topic (as this interp). F03/0055 is purely and simply about which model number to return the information for when the argument is not itself a model number. This (obviously) affects subnormals, but also affects other number systems such as double-double precision. It has no bearing on this question whatsoever. >The proposed revised specification for the intrinsic function SPACING >and the existing text are equivalent if the value of e\sub{min} is >chosen properly for the KIND of real value. That is not true. > The text that F03/0055 >added assumes that the value of e\sub{min} for a processor that >supports subnormal numbers is the exponent of the smallest positive >representable number. That is not true, and it is clear from the text of F03/0055 that none of the questioners and answerers thought such a thing! I quote the question: "What results do SPACING and RRSPACING return if the value of X lies outside the model of 13.4, in particular if it is denormal?" This question would have no meaning if subnormal numbers were model numbers. > The Fortran 2008 standard does not spell out how the value of >e\sub{min} is to be chosen, Yes, we are expecting the vendor to do the "right thing". The "reasonable" (perhaps naive) expectation is that it will be chosen to be the most negative number for which all model numbers are machine numbers, and for which arithmetic (on model numbers) works correctly. The latter consideration is pretty much moot these days, assuming correctly-functioning hardware, since conformance to IEEE arithmetic requires this and much more. Whether subnormal numbers exist does not affect this value, since the including the exponent values of subnormal numbers in the model would result in MANY model numbers which would not be representable. That is, rather obviously, not a reasonable result! > which must be >addressed if the results of the intrinsic function SPACING are to be >fully specified. The results of the intrinsic function SPACING ***ARE*** fully specified. It returns the spacing of model numbers. That model numbers are not themselves fully specified by the standard is completely irrelevant. >If a different value of e\sub{min} is chosen, the result of SPACING >for the value 0.0 becomes problematic. For example, if the value of >e\sub{min} is chosen to be -126 for IEEE single-precision, the value >of >SPACING(0.0) will be 1.1754944E-38, while the value of >SPACING(X) for a nonzero subnormal value will be 1.4012985E-45. >SPACING(0.0) should not be greater than SPACING(X). That is just completely and utterly wrong. The fact is that the spacing of *normal* model numbers between TINY and 2*TINY is much much smaller than the spacing of model numbers around zero. In fact for single precision the spacing of model numbers is less than TINY in the range TINY to TINY*2**23 i.e. quite a large range, and for double precision an even bigger range. When we added an intrinsic to return the spacing of model numbers, we specified (and expected!) it to return the spacing of model numbers, or a reasonable approximation if the exact spacing of the model numbers in question was not representable (as it is for smallish numbers when subnormals are not available). When subnormals are available, they are unsuitable (as explained above) to be model numbers, but they happen to be ideally suited to returning the actual spacing of small numbers. Bill Long's yes vote with Comment on F08/0123: I would like to see the resolution of Robert Corbett's comment on this interp. The interp he mentioned, F03/0055, appears to have passed and was included in Corrigendum 1 of F2003. Van Snyder's No vote on F08/0123: I agree with Bob Corbett that spacing(0.0) ought not be greater than spacing(X) when X is subnormal. Malcolm Cohen's comments on Van's no vote: >I agree with Bob Corbett that spacing(0.0) ought not be greater than >spacing(X) when X is subnormal. (a) that does not appear to be what Bob Corbett is saying; (b) this interp is not addressing the issue of which spacing to return when the argument is not a model number (the topic of F03/0055). I have some sympathy with the argument that F03/0055 gives the wrong specification when X is not a model number; one might have thought that when X is not a model number, it is in between two model numbers, ***And Therefore The Spacing It Returns Should Be The Space Between Those Model Numbers***! However, that is not what we decided for F03/0055. Again, F03/0055 is not just about subnormals... (though that's probably where most would see the effects). I have no objection at all to revisiting F03/0055, but I don't see why we have to do that before answering this interp. (There are at least three plausible - maybe even reasonable - choices of algorithm for deciding which model number to return the spacing for...) Result for F08/0123: /INTERP does not agree with Robert or Van's comments. /INTERP is not opposed to someone revisiting interp F03/0055. F08/0123 passed by J3 letter ballot. F08/0124 Coindexed object with polymorphic subcomponent Bill Long's yes vote with Comment on F08/0124: While I agree there is a defect that needs attention, the proposed "potential subobject component" term is awkward at best, and has a recursive definition. And the resulting constraint would end "has a polymorphic allocatable potential subobject component". Not an example of clarity. And it appears to say "allocatable nonpointer" which is automatically true, since allocatable and pointer are mutually exclusive. Malcolm Cohen commented on Bill's yes with comment vote on F08/0124: >For F08/0124: >------------- > >While I agree there is a defect that needs attention, the proposed >"potential subobject component" term is awkward at best, (a) That is a matter of opinion. Some might think it the best descriptive term available. (b) This is an interp. Improving the wordsmithing of a term is not necessary and should not be done unless there is an actual better candidate waiting in the wings. (c) It took us a long time indeed to come up with a term even as good as this one... > and has a recursive definition. I should hope so too! That is what the question in the interp was about... That's why we defined it properly as a special term - even though this interp only needs to use it in one place. > And the resulting constraint would end "has a polymorphic >allocatable potential subobject component". Not an example of >clarity. The constraint is concerned about having (a component that is): (a) polymorphic (b) allocatable (c) a component whose corresponding structure component is potentially a subobject (of the base object of the data-ref), i.e. a potential subobject component Seems pretty clear to me. Verbose, but not unclear. > And it appears to say "allocatable nonpointer" which is >automatically >true, since allocatable and pointer are mutually >exclusive. The text "allocatable nonpointer" does not and will not appear in the standard. We could delete the "allocatable" word since a potential subobject component is never a pointer component and therefore polymorphic implies it is necessarily allocatable, that gives us "has a polymorphic potential subobject component". I don't object strongly to that, but it does require the reader to "prove the lemma" that this is necessarily allocatable (otherwise they *might* get confused about polymorphic pointer components). Anyway, deleting "allocatable" (or not) is wordsmithing at a level not strictly necessary for an interp. Result for F08/0124: /INTERP does not agree with Bill's comments. F08/0124 passed by J3 letter ballot. ------------------------------------------------------------------------ NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: In the description of the VALUE attribute, [101:23-24] section 5.3.18p1, constraint C558 disallows the VOLATILE attribute with the VALUE attribute: "C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or VOLATILE attributes." But there is no prohibition of the ASYNCHRONOUS attribute with the VALUE attribute. Should this combination also be disallowed? ANSWER: No, the combination of VALUE and ASYNCHRONOUS attributes should not be disallowed. That is, the combination of VALUE and ASYNCHRONOUS attributes should continue to be allowed. A dummy argument with the VALUE attribute is not argument associated with the corresponding actual argument. Rather, it is associated with an anonymous data object whose value is copied from the actual argument before execution of the executable constructs of the subprogram commences, and before expressions in the specification part are evaluated. Therefore, it can successfully take part in asynchronous operations that both start and complete within that procedure call, independently of whether the corresponding actual argument has or has not the ASYNCHRONOUS attribute. There is no problem if a dummy argument has the VALUE attribute and the corresponding actual argument has the ASYNCHRONOUS attribute, independently of whether the dummy argument has the ASYNCHRONOUS attribute. Subclause 9.6.4.1, paragraph 6 [220:13-15], prohibits an actual argument that is part of a pending input/output storage sequence affector from being associated with a dummy argument that has the VALUE attribute. EDIT to 10-007r1: None. SUBMITTED BY: Stan Whitlock HISTORY: 14-109 m203 F08/0105 submitted - disallow failed 14-109r1 m203 try allow - passed by J3 meeting 14-192 m204 Failed J3 letter ballot #30 14-146 14-269 m205 Revised answer - Passed by J3 meeting 15-xxx m206 Passed as amended by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTIONS: 1. Are the following INQUIRE statements permitted? LOGICAL :: Exist, Opened INQUIRE ( FILE='fred', EXIST=exist ) INQUIRE ( UNIT=42, OPENED=opened ) 2. Is the following INQUIRE statement permitted? INTEGER :: U INTERFACE FUNCTION P ( A ) INTEGER, INTENT(IN) :: A INTEGER, POINTER :: P END FUNCTION P END INTERFACE INQUIRE ( FILE='fred', NUMBER=u, POS=p(u) ) 3. Is the following READ statement permitted? INTEGER :: STATS(42) NAMELIST /IN/ V READ ( *, IN, IOSTAT=STATS(V) ) ANSWERS: 1. According to 9.12p5 [243:3-5] "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statements are prohibited because the values of the variables EXIST and OPEN depend upon the values of the FILE= and UNIT= specifiers, respectively. They were intended to be permitted. Edits are provided to correct this mistake. 2. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statement is not prohibited because U is not a subscript or substring bound. According to 7.1.4p2 [139:3-4] "The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." the INQUIRE statement is not prohibited because, although U is assigned a value, it is not evaluated. The INQUIRE statement was intended to be prohibited. Edits are provided to correct this mistake. 3. According to 9.12p6 [243:6-8] "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." and 9.12p7 [243:9-11] "In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if any, shall not be associated with any entity in the ... ...." and 9.12p8 [243:12-14] "In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an array element reference, its subscript values shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the ." the READ statement is not prohibited because V does not "depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." Although V is input from namelist, it is not "the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier." The READ statement was intended to be prohibited. Edits are provided to correct this mistake. EDITS to 10-007r1: [243:3-5 9.12p5] Within the second sentence, provided by Corrigendum 2, replace "values of any or" with "value of any". Append ", or be affected by data transfer caused by that statement". That sentence becomes "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT=, or SIZE= specifier shall not depend on the value of any in the same statement, or be affected by data transfer caused by that statement." {Using "data transfer" instead of "" covers the namelist case.} [243:6-7 9.12p6] Replace "value of any subscript or substring bound" with "denotation". Replace "depend ... " with "be affected by the data transfer, the processing". The paragraph becomes "The denotation of a variable that appears in a specifier in an input/output statement shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the or in that statement." After the paragraph, insert a note: NOTE 9.nn The semantics of how a variable is denoted is its "denotation"; this includes such things as component and array element selection. Anything that affects this process is prohibited in this context; that includes the values of any subscripts used, and if the variable is specified by a pointer function reference, anything that affects the evaluation of that function. {Using "data transfer" instead of "" covers the namelist case.} [243:9 9.12p7] "Insert "ID=," before "IOSTAT". {Not mentioned in a question, but was a problem.} [243:12-14 9.12p8] Repairing the paragraph would make it equivalent (if not identical) to 9.12p6, as revised above. Therefore, delete the paragraph. SUBMITTED BY: Van Snyder HISTORY: 14-193 m204 F08/0110 submitted 14-193r1 m204 Revised 14-272r1 m205 Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0115 TITLE: ASYNCHRONOUS and argument passing KEYWORD: ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider PROGRAM Main INTEGER, ASYNCHRONOUS :: array(5) = -1 OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read') CALL async_read(array) CALL fred(array(::2)) ! Problematic? WAIT (11) PRINT *, array CONTAINS SUBROUTINE async_read(array) INTEGER, ASYNCHRONOUS, INTENT(INOUT) :: array(:) READ (11, *, ASYNCHRONOUS='yes') array END SUBROUTINE END PROGRAM SUBROUTINE Fred (arg) ! In general, an external procedure INTEGER :: arg(*) ! Otherwise unused CONTINUE ! In general, something that takes more time END SUBROUTINE Is the call to "Fred" standard-conforming? It is not excluded by 5.3.4p2, because 'array' is merely associated with 'arg' in subroutine Fred, and not used in any executable statement or specification expression there. However, if copy-in/out is used for argument passing and the actual i/o transfer occurs in between the copy-in and copy-out, the wrong answers will be given. ANSWER: This program was not intended to be conforming. An edit is provided to correct this oversight. EDITS: [90:15] 5.3.4 ASYNCHRONOUS attribute, p2, first bullet, between "the variable" and "appears" insert "is a dummy argument or". SUBMITTED BY: Nick Maclaren HISTORY: 14-218 m205 F08/0115 submitted 14-218r1 m205 Revised 14-218r2 m205 Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0116 TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: In all cases, Alf is a Fortran procedure like this: SUBROUTINE Alf (Arg) BIND(C,NAME='Alf') INTERFACE SUBROUTINE Arg () BIND(C) END SUBROUTINE Arg END INTERFACE CALL Arg END SUBROUTINE Alf Q1. Consider extern void Bert (void) { ; } int main (void) { Alf(Bert); } 15.5.1p2 requires a procedure defined by means other than Fortran to have the same binding label as the interface. Function Bert() has a binding label of 'Bert', but 15.5.2p2 states that the dummy argument Arg has no binding label, therefore 15.5.1p2 is not satisfied. Was this intended to be conforming? Q2. Consider static void Fred (void) { ; } int main (void) { Alf(Fred); } 15.5.1p2 requires a procedure defined by means other than Fortran to have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999. Function Fred() has no such name, as its definition has internal linkage. However, linkage in C affects only the visibility of the external name, and has no application to either types or values, whether in the form of function parameters or other pointers. Was this intended to be conforming? Q3. Consider extern inline void arg (void) { ; } int main (void) { Alf(Joe); } C99 6.7.4 describes the inline specifier. This does not prevent it from having external linkage, but "An inline definition does not provide an external definition for the function" i.e. despite having external linkage, there might be no external definition that could be invoked from Fortran. Was it not an oversight not to exclude inline in 15.5.1? ANSWERS: A1. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A2. Yes, this was intended to be conforming. An edit is provided to correct this mistake. A3. A C function with no external definition is not "defined by means other than Fortran" so much as "not defined". This was not intended to be conforming. An edit is provided to clarify this situation. EDITS: [436:15] 15.5.1 Definition and reference of interoperable procedures, p1, Append sentence "A C function that has an inline definition and no external definition is not considered to be defined in this sense.". In 15.5.1p2, apply these edits [436:16] After "means other than Fortran," delete "it shall", [436:17] Before "be describable" insert "it shall", after "the interface," insert "and", [436:18-19] Before "have a name" insert "if it is accessed using its binding label, it shall" and begin a bullet sub-list, and make the "have the same" bullet the second sublist item. This makes that whole paragraph read "If the procedure is defined by means other than Fortran, -- it shall be describable by a C prototype that is interoperable with the interface, and -- if it is accessed using its binding label, it shall - have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999, and - have the same binding label as the interface." {Note this wording uses "accessed" rather than "invoked" since it can be the argument of C_FUNPTR or the target in a procedure pointer assignment.} SUBMITTED BY: Nick Maclaren HISTORY: 14-221 m205 F08/0116 submitted 14-221r1 m205 Revised 14-221r2 m205 Further Revised - Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0117 TITLE: TARGET and coindexed arguments KEYWORD: TARGET, coindexing DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following program conforming and required to print 10, 10, 10 and 123, 123, 123? PROGRAM Main INTEGER, TARGET :: coarray(3)[*] coarray = 10*THIS_IMAGE() SYNC ALL IF (THIS_IMAGE() == 1) THEN SYNC ALL coarray = 123 SYNC ALL ELSE IF (THIS_IMAGE() == 2) THEN CALL Fred(coarray(:)[1]) ELSE SYNC ALL SYNC ALL END IF CONTAINS SUBROUTINE Fred (arg) INTEGER, TARGET :: arg(:) PRINT *, arg SYNC ALL SYNC ALL PRINT *, arg END SUBROUTINE Fred END PROGRAM Main DISCUSSION: This program is modifying an actual argument while it is associated with a dummy argument. That is normally prohibited by the anti-aliasing rules in 12.5.2.13, but these do not operate in the TARGET dummy argument case. However, coindexed actual arguments are accessing remote memory, so in general will be passed by copy-in/out; in this case permitting aliasing is not reasonable. ANSWER: The program is not intended to be conforming. Edits are provided to correct this oversight. EDITS: [300] 12.5.2.13p1(3)(b) append to the end of the paragraph "or a coindexed object". [300] 12.5.2.13p1(4)(b) append to the end of the paragraph "or a coindexed object". SUBMITTED BY: Nick Maclaren HISTORY: m205 14-223 F08/0117 submitted m205 14-223r1 Revised example and discussion - Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0118 TITLE: Subobject of variable in variable definition context KEYWORD: subobject, variable definition context DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Does this program conform to the Fortran 2008 standard? type :: T integer :: C end type T type(t), parameter :: V = T(41) associate ( W => V ) 1 w%c = 42 end associate end DISCUSSION: Because the selector is not permitted to appear in a variable definition context, the associate-name is not permitted to appear in a variable definition context. However, that does not affect subobjects of the associate-name. ANSWER: The associate-name is not permitted to appear in a variable definition context because no interpretation is established; however, it should be explicitly stated that this is not permitted. An edit is provided to clarify this. EDITS: [170:19] 8.1.3.1 Purpose and form of the ASSOCIATE construct, C801, Between "" and "shall not appear" insert "or any subobject of ". [171:12] 8.1.3.3 Attributes of associate names, p2, Between "the associate name" and "shall not appear" insert "or any subobject of the associate name". [184:13] 8.1.9.1 Purpose and form of the SELECT TYPE construct, C836, Between "" and "shall not" insert "of any subobject of ". SUBMITTED BY: Van Snyder HISTORY: 14-240r1 m205 F08/0118 submitted 14-240r2 m205 Revised question and answer - Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0119 TITLE: Branching to END BLOCK and END CRITICAL KEYWORD: Branching, END BLOCK, END CRITICAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Do the GO TO statements in the following conform to the Fortran 2008 standard? go to 1 block 1 end block go to 2 critical 2 end critical ANSWER: Branching to an END BLOCK or END CRITICAL statement from outside the construct was intended to be prohibited. Edits are provided to correct this omission. EDITS: [172:13+] 8.1.4 BLOCK construct, after p3 (before NOTE 8.5), Insert new paragraph "It is permissible to branch to an 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 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 ... ." [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 , , , , , , or , 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-xxx m206 Passed as amended by J3 letter ballot 14-279 ------------------------------------------------------------------------ NUMBER: F08/0120 TITLE: Is the name of a procedure pointer a local identifier? KEYWORDS: name procedure pointer DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the name of a procedure pointer a local identifier? The list of classes of local identifiers given in paragraph 1 of subclause 16.3.1 of J3/10-007r1 (page 440) does not include procedure pointers. ANSWER: Yes, if a procedure pointer is named, the name of the procedure pointer is a local identifier. An edit is provided to amend the oversight. EDITS: [440:4, 16.3.1p1] Replace "named constants, named" with "named constants, named procedure pointers, named". SUBMITTED BY: Robert Corbett HISTORY: 14-256 m205 F08/0120 submitted - Passed by J3 meeting 15-xxx m206 Passed as amended by J3 letter ballot 14-279 ------------------------------------------------------------------------ NUMBER: F08/0121 TITLE: Add to introduction defined operations in specification exprs KEYWORDS: specification, restricted, defined operator DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Fortran 2003 7.1.6 (Specification expressions), says on 141:12: A restricted expression is an expression in which each operation is intrinsic Fortran 2008 7.1.11 says on 150:8: A restricted expression is an expression in which each operation is intrinsic or defined by a specification function This new feature is not called out in the Introduction but should be. ANSWER: This was an oversight. An edit to correct the problem is supplied. EDIT to 10-007r1: Introduction, page xv. Add to the "Data declaration" list in paragraph 2: "A 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 "" - Passed by J3 meeting 15-xxx m206 Passed as amended by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0122 TITLE: Types with coarray components KEYWORD: Coarrays, derived types DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTIONS: Q1. Consider Module m Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] Contains Subroutine dubious Volatile x Volatile xco ... End Subroutine End Module Program bad Use m Volatile x Volatile xco ... End Program 5.3.19 C560 says "The VOLATILE attribute shall not be specified for a coarray that is accessed by use (11.2.2) or host (16.5.1.4) association." That means that the two "VOLATILE XCO" statements are not conforming. However, the "VOLATILE X" statements have essentially the same effect, but are unaffected by the constraint, which seems inconsistent. Was this constraint also intended to apply to objects with coarray components? Q2. Consider Program blockvolatile Type t Real,Allocatable :: co[:] End Type Type(t) x Real,Allocatable :: xco[:] ... Block Volatile x Volatile xco End Block 5.3.19 C561 says "Within a BLOCK construct (8.1.4), the VOLATILE attribute shall not be specified for a coarray that is not a construct entity (16.4) of that construct." That means that VOLATILE XCO is not standard-conforming. However, the constraint apparently does not apply to X, so VOLATILE X is standard- conforming, even though it has essentially the same effect as the forbidden case. Was this constraint intended also to apply to objects with coarray components? Q3. 5.3.19p1 says "A noncoarray object that has the VOLATILE attribute may be associated with an object that does not have the VOLATILE attribute..."; does this apply to objects with a coarray component? Q4. 12.4.2.2p1 says "A procedure other than a statement function shall have an explicit interface if it is referenced and ... (2) the procedure has a dummy argument that ... (c) is a coarray, ...." Is this intended also to apply to objects with coarray components? Q5. Consider: Program volatility Type t Real,Allocatable :: co[:] End Type Type(t) :: x Type(t),Volatile :: y ... Call s1(x) Call s2(x) ! Dummy is volatile, X is not. Call s1(y) ! Y is volatile, dummy is not. Call s2(y) Contains Subroutine s1(a) Type(t) :: a ... End Subroutine Subroutine s2(b) Type(t),Volatile :: b ... End Subroutine End Program 12.5.2.8p1 says "If the dummy argument is a coarray, the corresponding actual argument shall be a coarray and shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." That means that if the program were passing the component CO directly (and the TYPE(T) declarations in S1 and S2 were changed to REAL), the second and third calls would not be conforming because of the VOLATILE mismatch. It seems inconsistent that there is no requirement for VOLATILE to match when there are coarray components, since it has the same effect that X%CO is VOLATILE in S2 but not in the caller, and Y%CO is VOLATILE in the caller but not in S1. Was this requirement also intended to apply to objects with coarray components? Q6. 12.8.1 C1289 says "All dummy arguments of an elemental procedure shall be scalar noncoarray dummy data objects and shall not have the POINTER or ALLOCATABLE attribute." Is this intended also to apply to objects with coarray components? ANSWER: A1. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A2. Yes, this constraint was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A3. No, this does not apply to objects with coarray components, as there is no way of giving the noncoarray parts of the object the VOLATILE attribute without giving the coarray part the VOLATILE attribute, which is forbidden. That the quoted text gives permission for a noncoarray to have the VOLATILE attribute does not override any other requirements in the standard. A4. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. A5. Yes, this requirement was intended to apply to objects with coarray components. An edit is supplied to correct this omission. A6. No. A dummy argument that has a coarray component is still just an ordinary dummy argument, so this text does not apply. EDITS: [102:9] 5.3.19 VOLATILE attribute, C560, Between "for a coarray" and "that is accessed by use or" insert ",or a variable with a coarray ultimate component,". {A1.} [102:11] 5.3.19 VOLATILE attribute, C561, Between "for a coarray" and "that is not a construct entity" insert ",or a variable with a coarray ultimate component,". {A2.} [295:4+] 12.5.2.4 Ordinary dummy variables, p18+, "If the dummy argument has a coarray ultimate component, the corresponding actual argument shall have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute." {A5.} SUBMITTED BY: Nick Maclaren HISTORY: 14-228 m205 F08/0122 submitted 14-228r1 m205 Revised questions with answers - Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0123 TITLE: SPACING intrinsic KEYWORDS: SPACING DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program Program test_spacing Real :: x, y, tiny_spacing, z x = Tiny(x) y = Nearest(x,1.0) tiny_spacing = y - x If (tiny_spacing>0) Then ! Probably IEEE arithmetic with subnormals: ! the spacing y - x is representable. Else ! Probably no subnormals, so y - z is not representable. tiny_spacing = Tiny(x) End If z = Spacing(x) If (z/=tiny_spacing) Then Print *,'FAIL' Else Print *,'ok' End If End Program Furthermore let us assume that the processor supports IEEE arithmetic with subnormals, and that default REAL is IEEE single precision. According to Fortran 95, the result for SPACING is: "If X is not zero, the result has the value b**(e-p), where b, e, and p are as defined in 13.7.1 for the model representation of X, provided this result is within range." therefore the program is expected to print the value "ok". However, according to Fortran 2008, the result for SPACING is: "If X does not have the value zero ..., the result has the value b**max(e-p,emin-1), where ..." Unsurprisingly, e-p is not equal to max(e-p,emin-1) for smallish numbers, and therefore the program would be expected to print the value "FAIL". However, there is no such incompatibility with Fortran 90/95 listed in clause 1, therefore the standard contradicts itself. (The value specified in Fortran 2008 also contradicts the Description of the function which says "Spacing of model numbers (13.4)", since it does not even attempt to return that value.) Is the new specification a deliberate incompatibility or a mistake? DISCUSSION: The description of SPACING was changed in Fortran 2003 by paper 01-361r2 "Comments on Section 13", which contains no justification for this technical change and indeed does not even mention it is a technical change - there is just the bare edit (buried in a huge list of bare edits) with no indication as to why. This would seem to indicate that the technical change is an inadvertent error (presumably the paper simply forgot about subnormal numbers and assumed the new formula gave the same result as the old one). ANSWER: The new wording of SPACING inadvertently changed the return values when IEEE subnormal values were available. An edit is provided to correct this mistake. EDITS to 10-007r1: [389:4-5] 13.7.157 SPACING (X), p5 Result Value, Change "max(e-p,emin-1)" to "e-p", After "that of X" insert ", provided this result is representable; otherwise the result is the same as that of TINY (X).", Change "; if there are two such values" to "If there are two extended model values equally near to X,". This makes the whole paragraph read: If X does not have the value zero and is not an IEEE infinity or NaN, the result has the value b**(e-p), where b, e, and p are as defined in 13.4 for the value nearest to X in the model for real values whose kind type parameter is that of X, provided this result is representable; otherwise the result is the same as that of TINY (X). If there are two extended model values equally near to X, the value of greater absolute value is taken. If X has the value zero, the result is the same as that of TINY (X). If X is an IEEE infinity, the result is an IEEE NaN. If X is an IEEE NaN, the result is that NaN." where "b**(e-p)" represents the typesetting of $b^{e-p}$. SUBMITTED BY: Malcolm Cohen HISTORY: 14-263 m205 F08/0123 submitted - Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ---------------------------------------------------------------------- NUMBER: F08/0124 TITLE: Coindexed object with polymorphic subcomponent KEYWORD: Coindexed object, polymorphic subcomponent DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following type definitions and object declarations: Type t1 Class(*),Allocatable :: bad End Type Type t2 Type(t1),Allocatable :: oops End Type Type(t1) x[*] Type(t2) y[*] Do the following subroutine calls conform to the Fortran 2008 standard? Call s1(x[2]) Call s2(y[2]) DISCUSSION: If Y[2]%OOPS and Y[2]%OOPS%BAD are both allocated they are subobjects, but only OOPS is a subcomponent of Y[2]. Since OOPS is not polymorphic and BAD is not a subcomponent, this clearly does not violate C617. That seems inconsistent since in both cases a copy of the coindexed variable would necessarily copy the polymorphic BAD component. ANSWER: The intent of C617 was to prevent copying a polymorphic subobject of a coindexed object. Since a subobject is not always a subcomponent, an edit is provided to correct the mistake of using the term "subcomponent" in C617. EDITS: [6:7+] After 1.3.33.2 parent component, insert new term "1.3.33.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component" {We need a new term to describe this properly.} [119:13 C617] Replace "subcomponent" with "potential subobject component". SUBMITTED BY: Van Snyder HISTORY: 14-262 m205 F08/0124 submitted - Passed by J3 meeting 15-xxx m206 Passed by J3 letter ballot 14-279 ----------------------------------------------------------------------