12-165r1 To: J3 From: Stan Whitlock/Malcolm Cohen Subject: Results of the J3 interp letter ballot #25 Date: 2012 June 27 Here are the results of J3 letter ballot #25 on Fortran interpretations that officially closed 22-Jun-2012. The ballot is in J3 paper 12-147r1 for meeting #198. If I have transcribed a vote or a comment incorrectly, please let me know. The first row in each table is the result of this vote. Row two indicates the interps that were in LB #24 in 11-241. 18 of 20 interps in LB #24 passed; F03/0120 and F08/0055 failed. F03/0120 passed J3 meeting #197; F08/0055 was not modified. Unfortunately all 20 of the interps from LB #24 {18 of them marked "Passed J3 letter ballot" were in LB #25, where some of them failed. /INTERP at meeting 198 will decide the fate of the LB #24 interps. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 017 018 019 021 046 053 065 084 096 103 116 118 result of #25 Y Y Y Y Y Y Y C Y Y Y Y passed #24 * * * * * * * * * * * Dan Chen Y Y Y Y Y Y Y Y Y N Y Y Malcolm Cohen Y Y Y Y Y Y Y Y Y Y Y Y Robert Corbett Y Y Y Y Y Y Y N Y Y Y Y Bill Long Y N Y Y Y C Y C Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen no vote received John Reid Y Y Y Y Y N Y N Y Y Y Y Van Snyder Y Y Y Y Y N Y N Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y J3 rep F03 F03 F03 F08 F08 F08 F08 F08 F08 F08 F08 F08 120 121 004 008 031 032 038 040 042 043 048 054 result of #25 Y Y Y C Y Y Y N C C Y Y passed #24 n Dan Chen Y Y Y Y Y Y Y Y Y Y Y Y Malcolm Cohen Y Y Y Y Y Y Y N Y Y Y Y Robert Corbett Y C Y C Y Y Y N Y Y Y C Bill Long Y Y Y C Y Y Y N Y C Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen no vote received John Reid Y Y Y Y Y Y Y N C C Y Y Van Snyder Y N Y Y Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 055 056 057 058 059 060 061 062 063 064 065 066 result of #25 C Y C Y C Y C Y Y Y C C passed #24 n * * * * * * * Dan Chen Y Y Y Y Y Y Y Y Y Y C Y Malcolm Cohen Y Y Y Y Y Y Y Y Y Y N N Robert Corbett C N Y N Y Y Y Y C Y Y Y Bill Long C Y Y Y C Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen no vote received John Reid C Y Y Y Y Y Y Y Y Y Y N Van Snyder Y Y C C C Y C Y Y Y Y C Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y J3 rep F08 F08 F08 F08 F08 F08 F08 067 068 069 070 071 072 073 result of #25 Y C Y C N Y C passed #24 Dan Chen Y Y Y Y Y Y Y Malcolm Cohen Y Y Y Y Y Y Y Robert Corbett C Y Y Y Y Y Y Bill Long C Y Y Y Y Y C Dan Nagle Y Y Y Y Y Y Y Craig Rasmussen no vote received John Reid Y C Y Y N Y N Van Snyder N N Y C C Y Y Stan Whitlock 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; within an interp, each indiviual comment is separated by 6 "*"s. The interps marked "C" pass with some minor fixes, as noted below. The interps marked "?" fail and need to be reviewed by /INTERP at meeting 198. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F03/0018 Multiple identical specific procedures in type-bound generic interfaces Bill Long's No vote on F03/0018: Generic resolution is based on differences between the interfaces of the specific procedures in the generic interface. The interface for a specific type-bound procedure is that of the (4.5.5p6), not that of the . In the examples, there is only one (myadd). Ambiguity is not possible if there is only one specific interface. Malcolm Cohen replied to Bill Long: >Generic resolution is based on differences between the interfaces of >the specific procedures in the generic interface. Yes. >The interface for a specific type-bound procedure is that of the > (4.5.5p6), not that of the . yes... >In the examples, there is only one (myadd). Yes... >Ambiguity is not possible if there is only one specific interface. ...no, this is precisely backwards! You have two generic results with the same interface! In Q1, that is (1) the specific type-bound procedure myadd_t (2) the specific type-bound procedure myadd_x These are separate entities, therefore ambiguous. In Q2, it is (1) the specific type-bound procedure myadd_t (2) the ordinary specific procedure myadd Again these are separate entities, therefore ambiguous. You can see the difference between these by considering dynamic dispatch: - dispatch to any type-bound procedure is done dynamically; - overriding specific type-bound procedures is by the specific name; - dispatch to an ordinary specific procedure is not dynamic. So after type extension and possible procedure overriding, these might give different results. But even if they don't give different results, in each case they are still Not The Same Entity. result of ballot on F03/0018: No change will be made as a result of these comments => F03/0018 passed unchanged. F03/0053 The BIND attribute for C_PTR and C_FUNPTR John Reid's No vote on F03/0053: 1. If these types do not have the BIND attribute, 15.3.3 should say so. The text of 15.3.3 is similar to 15.2.2 in the Fortran 2003 standard. In N1622, J3 thought it was unclear and proposed editing 15.2.2 to say that these types do have the BIND attribute. I suggest the edit: [431:2] 15.3.3, para 1. At the end of sentence 1 add "and without the BIND attribute". 2. No rationale is provided for the interpretation that a user-defined derived type with the BIND attribute is permitted to have private components. It seems to me that this should not be permitted since it destroys the purpose of declaring components to be private. Bill Long's Comment on F03/0053: I agree with John's comment that allowing private components in a BIND(C) type was unwise. Not only does this circumvent the goal of private components, but it would also interfere with a useful addition to interoperability should C ever introduce an idea similar to private struct members. The intent of the original C interoperability was to focus on areas where C and Fortran had comparable features. The list in 15.3.4p1 disallows most of the differences - were private components just overlooked? Malcolm Cohen replied to Bill Long: No, it was deliberate - very similar things happen with SEQUENCE and PRIVATE. I would agree that SEQUENCE+PRIVATE was also a mistake, but that water has flowed under the bridge, gone out to sea, evaporated, fallen as rain, sunk into the aquifer, been pumped out, used to irrigate the crops, and has gone under the bridge again. Anyway, BIND(C)+PRIVATE like SEQUENCE+PRIVATE basically has no effect on storage, only on the type system. As such, I can understand their decision (even though I disagree with it). Van Snyder's No vote on F03/0053: A case hasn't been made for C_PTR and C_FUNPTR not to be extensible. I can't think of a reason to want to extend one of these, but adding special-case prohibitions to the standard just makes things difficult for everybody, without measurable benefit. If a compelling case can be made that these ought not to be extensible, I will drop my objection. Malcolm Cohen responded to Van Snyder: >A case hasn't been made for C_PTR and C_FUNPTR not to be extensible. They are not structures. There is no case for C_PTR being extensible that does not apply to REAL(real64) being extensible. I do not think that this is reasonable. The measurable benefit is reduced complexity of implementation. C_PTR and C_FUNPTR already require some additional complexity as although they are derived types, they don't act like them. Furthermore, C_PTR is meant to be "void *", it is for interoperating with C, and C does not have any concept of type extension. Even C++ does not allow "void *" to be extended. The reduced complexity of implementation benefit is not overriding, but without any reason for allowing extension we should be conservative and disallow it. Furthermore, I think it highly unlikely that the subgroup which created C_PTR intended for it to be extensible, and I seriously doubt that anyone else even gave thought to it. All this argues against permitting extension. Additional comment from Malcolm Cohen at meeting 198: It is a fundamental principle that an entity only has an attribute if the standard says that it does. For this reason, John Reid's suggested edit no. 1 is unnecessary. result of ballot on F03/0053 No change will be made as a result of these comments => F03/0053 passes unchanged. ************************************************************************ F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine Bob Corbett's No vote on F03/0084: The answer given contradicts interpretation F90/000001. Interpretation F90/000001 imposes limitations on optimization across statements. It also requires conversions to type and type kind parameter values for assignments to a variable. Assuming the kind type parameter value sp corresponds to IEEE single-precision, neither the value of Z1 nor the value of Z2 after the assignments can be 0.67222259081253. Bill is correct that the example can be improved. I suggest changing the rounding modes to be IEEE_UP and IEEE_DOWN. Bill Long's Comment on F03/0084: Is there a missing line in the example code? It seems like there should have been CALL IEEE_SET_ROUNDING_MODE (IEEE_UP) just before the line Z1 = X*Y Otherwise the code seems pointless since round-to-nearest is the default on most systems. John Reid's No vote on F03/0084: The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. Van Snyder's No vote on F03/0084: 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 CALL IEEE_SET_ROUNDING_MODE(IEEE_DOWN) V%LOW_BOUND = X * Y CALL IEEE_SET_ROUNDING_MODE(IEEE_UP) 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. Malcolm Cohen responded to Van Snyder: This interp does nothing to inhibit interval arithmetic or otherwise. There are NO EDITS. /INTERP does not agree that there is any conflict with F90/000001, which is primarily about common subexpression elimination (and did not make any edit to the standard). /INTERP especially does not agree with John Reid's suggestion that a constant expression using IEEE data types is required not to be constant. /INTERP agrees with Bill Long and Bob Corbett's comment about improving the example. => F03/0084 passes as amended. F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type Daniel Chen's No vote on F03/0103: Passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy should be disallowed as it requires de-referencing the descriptor. There are rules that disallow passing a pointer dummy or allocatable dummy that is not present as actual argument to a nonpointer nonallocatable optional dummy (12.5.2.12p3 (7)/(8)). There should be a similar rule for prohibit passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy. Malcolm Cohen commented at meeting 198: When the dummy argument is not present, there is no need to dereference any descriptor that might or might not exist. result of ballot on F03/0103 No change will be made as a result of these comments => F03/0103 passes unchanged. F03/0121 Precise FP semantics of the REAL intrinsic Bob Corbett's Comment on F03/0121: According to F90/000001, assignment is sufficient, the variable assigned to does not need to have the VOLATILE attribute. The statement in the answer is correct, but more restrictive than necessary. Van Snyder's No vote on F03/0121: 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 7.1.5.2.4p3 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. Malcolm Cohen responded to Van Snyder: I am doubtful of this reasoning, but in any case I don't see how the answer is inconsistent with 13.7.1p2. The quote says "A program shall not invoke" i.e. the program is not standard-conforming. That is even less helpful to the user than what we are actually saying! In any case 13.7.1p2 is known to be broken... ...oh and it's quite easy for REAL to return something "not representable" in at least some floating-point arithmetics; just give it a boz with a bit pattern that is not possible (IEEE arithmetic makes all bit patterns meaningful, but other arithmetics do not always do that). >The caveat in 7.1.5.2.4p3 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. The phrase "mathematically equivalent" has no requirement not to produce a result that is in the "set of valid values for the type etc.", in fact the "different computational results" would lead one to think the exact opposite of this assertion. > The only reason ever to invoke the REAL intrinsic function with a > real argument is to provide a result value of the specified kind. Neither in the current, nor in previous Fortran standards, does it state that the "identify transformation" version of REAL is intended to force rounding to storage format. Much as I agree with the assertion that it is easy to guess that someone writing REAL(x,KIND(x)) might want to round X to storage format, that is not what the standard says. In fact since "REAL(X,KIND(X))" is mathematically equivalent to "(X)", the contrary behaviour (i.e. not rounding) is quite understandable. I would be very surprised if "(X)" were supposed to round to storage format, this would have huge performance implications on some platforms. result of ballot on F03/0121 No change will be made as a result of these comments => F03/0121 passes unchanged. F08/0008 IEEE exceptions for intrinsic functions Bob Corbett's Comment on F08/0008: I checked all of the intrinsic procedures defined in Clause 13, and found the proposed answer is suitable for all of them. Cases could be made for giving the functions NEAREST and SCALE special treatment, but I do not find those cases compelling. The rule for when to signal IEEE_INVALID could be made stronger. The rule given does not require signaling IEEE_INVALID if any of the actual argument values are infinite. Bill Long's Comment for F08/0008: The new paragraph at [325:12+] seems to lack context at the beginning. I assume we mean "is assigned or returned" as the result of invoking an intrinsic procedure. result of ballot on F08/0008: The interp will be modified by changing the edit for [325:12+] after "is assigned or returned" by inserting "by an intrinsic procedure"; F08/0008 => passes as amended. F08/0040 MOVE_ALLOC for coarrays Bill Long's No vote on F08/0040: An image control statement is sufficient to separate execution segments, but does not necessarily imply synchronization. But that is needed in the case where MOVE_ALLOC has coarray arguments and at least one of them is allocated on entry. You need all of the images to call the routine; effectively there is an internal SYNC ALL. Otherwise, if image X is calling MOVE_ALLOC while image Y is trying to reference the coarray being "moved", the references would likely be to the wrong memory locations. All of the images need to collectively agree on the new memory location. The edits do not seem to adequately cover this situation. John Reid's No vote on F08/0040: The argument TO of MOVE_ALLOC has INTENT (OUT). If it is not a coarray, this implies that it is deallocated on invocation. For a coarray, this is not allowed by C541, which says "An entity with the INTENT (OUT) attribute shall not be an allocatable coarray or have a subobject that is an allocatable coarray." This needs to be fixed. Do we really want to allow MOVE_ALLOC to be executed on some images and not on others? To support this case, a vendor that relies on symmetric memory would have to avoid deallocating TO and allow memory leakage, contrary to a prime objective of allocatable arrays. Furthermore, TO would not really be a coarray any more because of its hybrid nature, and this would be the case even if it is unallocated beforehand. If we are to allow MOVE_ALLOC for coarrays, we should make it imply synchronization, just like ALLOCATE and DEALLOCATE. I suggest these edits: [128:15] 6.7.1.2 Execution of an ALLOCATE statement, para 4. After "When an ALLOCATE statement is executed for which an allocate-object is a coarray" add "or a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC with coarray arguments is executed". [372:20] 13.7.118 MOVE ALLOC (FROM, TO), argument TO. Change "It is an INTENT(OUT) argument." to "It is an INTENT(INOUT) argument. On invocation of the procedure, it becomes deallocated." This seems to me to be too big a change to introduce in a corrigendum. I prefer the original suggestion (see N1875): In 13.7.118p3 MOVE_ALLOC (FROM, TO): [372:18] After "It shall be allocatable." in FROM, add "It shall not be a coarray." [372:19] After "It shall be allocatable." in TO, add "It shall not be a coarray." Malcolm Cohen's No vote on F08/0040: The result does not clearly explain the synchronisation requirements; these should be the same as for ALLOCATE and DEALLOCATE. I suggest the following additional edit. [372:29+] 13.7.118, p6+ Insert new paragraph immediately before "Example:" "When a reference to MOVE_ALLOC is executed for which the FROM argument is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the CALL statement is delayed until all other images have executed the same statement the same number of times." Bob Corbett's No vote on F08/0040: Having read Bill, John and Malcolm's comments, I agree that the answer given is not adequate. result of ballot on F08/0040: /interp will work further on the edits => F08/0040 fails. F08/0042 SOURCE= questions John Reid's Comment on F08/0042: In the edit for [127:18] 6.7.1.1 paragraph 4, replace "is permitted to be" by "shall be". Reason: I think this is our usual wording. The editor disagrees with this assertion, but agrees that the requirement could be better worded: [127:18] 6.7.1.1 paragraph 4, replace entirely with "If an is a coarray, the ALLOCATE statement shall not have a with a dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or which has a subcomponent whose dynamic type is LOCK_TYPE." {(Q2) Fix implied requirement of SOURCE= appearance for coarrays.} result of ballot on F08/0042: The change suggested by the editor will be made => F08/0042 passes as amended. F08/0043 Executing a type-bound procedure on a coindexed object Bill Long's Comment for F08/0043: The restriction on having a polymorphic coindexed actual argument only correspond to a dummy argument that is not polymorphic is quite restrictive since essentially all type-bound procedures have polymorphic passed-object arguments (C456). When I tried the example program with one compiler, it compiled and executed without error and produced the expected output. We might want to consider some relaxation of this restriction in the next standard. Removing the redundant constraint C1229 does not seem to rise to the level of fixing an error in the standard. This could be put off to the next standard. John Reid's Comment on F08/0043: I wonder if we need to remove a redundant constraint in a corrigendum. I think this could be transferred to the editor's list of editorial changes for the next revision. result of ballot on F08/0043: /INTERP agrees with these comments => F08/0043 passes as amended. F08/0054 Requirements for needing an explicit interface Bob Corbett's Comment on F08/0054: After reviewing this part of the standard, I think it needs a major overhaul. I am not prepared to propose changes at this time, and so I am voting "yes with comment." result of ballot on F08/0054: F08/0054 passes unchanged. F08/0055 G editing for reals Bob Corbett's Cooment on F08/0055: I agree that Thomas Henlich's proposed changes improve the edits. Bill Long's Comment for F08/0055: Given the complexity of the edits, it would be quite helpful if the answer to the questions included the expected output based on the new text. John Reid's Comment on F08/0055: (Originating from Thomas Henlich). In the new text for [258:15-19], k is undefined in the last sentence and the remark that it has no effect in the other case has been removed. I suggest swapping the last two sentences, then adding ", where \si{k} is the scale factor (10.8.5)" at the end of the sentence that is now first and "the scale factor has no effect and" after the comma in the sentence that is now last. result of ballot on F08/0055: /INTERP agrees with Thomas Henlich's comment => F08/0055 passes as amended. F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE= Bob Corbett's No vote on F08/0056: Allowing a polymorphic SOURCE= specifier in an ALLOCATE statement for a nonpolymorphic object seems likely to lead to errors that will be difficult to detect. I would prefer to ban the usage with a constraint. A user could get the same effective semantics by putting a SELECT TYPE construct around the ALLOCATE statement. That would go a long way toward ensuring that a user meant what he wrote. result of ballot on F08/0056: No change will be made as a result of these comments => F08/0056 passes unchanged. F08/0057 Interoperability with empty types Van Snyder's Comment on F08/0057: I would put the new constraint before C1501. result of ballot on F08/0057: /INTERP agrees that the suggested position (after C1505) is suboptimal; the new constraint would be better immediately before C1505 (not C1501) since both are talking about components; F08/0057 passes as amended. F08/0058 ENTRY point RESULT variable Bob Corbett's No vote on F08/0058: The answer given runs contrary to the sense of the answer given for interpretation F03/0110. A compiler that is able to handle that the example given in that interpretation would surely be able to handle the example in this interpretation. Just as there was no reason to change the semantics for interpretation F03/0110, there is no need to change the semantics for this interpretation. Van Snyder's Comment on F08/0058: 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 interp. Malcolm Cohen replied: There is no question. A dummy argument is not a function result, ergo we are talking about two different variables, that is class (1) entities with the same name in the same scoping unit. This is already forbidden by the scoping rules. result of ballot on F08/0058 No change will be made as a result of these comments => F08/0058 passes unchanged. F08/0059 Auto-targetting requirements Bill Long's Comment for F08/0059: The edit for [295:16-17] seems to make the edit in F08/0073 redundant. Van Snyder's Comment on F08/0059: Delete "and" from the edit for [295:16-17], or replace "with" by "that has" result of ballot on F08/0059 The first change suggested by Van Snyder will be made => F08/0059 passes as amended. F08/0061 Description of the CONTIGUOUS attribute misworded? Van Snyder's Comment on F08/0061: WG5/J3 ought to decide whether to include the suggested addition to a future standard in 008. result of ballot on F08/0061 The suggested addition will be removed from the interp and passed to the editor => F08/0061 passes as amended. F08/0063 G editing to a narrow output field Bob Corbett's Comment on F08/0063: While the interpretation given is technically correct, it clearly avoids answering the question the submitter meant to ask. result of ballot on F08/0063 The submitter confirmed (by private email) that he is happy with the question and answer as is => F08/0063 passes unchanged. F08/0065 Should certain procedures in intrinsic modules be pure? Daniel C Chen's Comment on F08/0065: IEEE_SET_FLAG and IEEE_SET_HALTING_MODE are not pure as they set hardware registers or global flags. They are currently classified as PURE subroutines in the standard. An edit should be needed to address this. Malcolm Cohen replied at meeting 198: Floating-point arithmetic can change the IEEE flags and it would be unfortunate if arithmatic were not permitted in a pure procedure. Malcolm Cohen's No vote on F08/0065: The procedures in ISO_C_BINDING can easily be used to circumvent the constraints on a PURE procedure regarding pointer operations and global variables, and therefore should not be permitted within a PURE procedure. Even if we were to permit that, making these PURE would be a change to Fortran 2003 which should therefore be mentioned in the Introduction. I suggest changing ANSWER 3 to "No.", and deleting the third edit (to 426:15). result of ballot of F08/0065 The changes suggested by Malcolm Cohen will be made => F08/0065 passes as amended. F08/0066 Are certain expressions with pointer initialization constant? John Reid's Comment on F08/0066: 1. I think a simple "Yes" is an inadequate response to question (1). The type declaration could be in a subprogram and V be a dummy argument. In this case, is T(V) really a constant expression? 2. The edit relies on the term "initialization target". As far as I can see, this is not defined. The only occurrence I found is in item 3(b) in the list at the start of 7.1.12. Could this item be reworded "a pointer component that is associated with a target by default initialization ..."? I tried to see if default initialization excluded the case where the target is a dummy argument but did not find it. 3. There is no explanation of why an "expression involving TRANSFER of an initialization target" gives special problems. Malcolm Cohen replied to John Reid: 1. V has the SAVE attribute so cannot be a dummy argument. 2. I agree about "initialization target". 3. The address of an initialization target is frequently done at link time or execution load time, not at compile time; this leads to implementation problems for TRANSFER and subsequent operations. Malcolm Cohen's No vote on F08/0066: The term "initialization target" should be avoided, change the edit "whose value was given by an initialization target" to "that is not disassociated" (alternatively, "that is not associated with a target" is ok, but the shorter version works). Alternatively, to avoid the double negative, replace the edit for [152:7+] with [152:7+] After item (7) "... NULL ...", insert new item "(7a) A reference to the intrinsic function TRANSFER where each argument is a constant expression and each ultimate pointer component of the SOURCE argument is disassociated." Van Snyder's Comment on F08/0066: ", TRANSFER" in the edit for [152:4] should be ", or TRANSFER" Edit for [152:7+] should be at [152:6+] result of ballot on F08/0066 Van Snyder's and Malcolm Cohen's changes are accepted => F08/0066 passes as amended. F08/0067 Passing arrays of extended type objects Bill Long's Comment for F08/0067: I think the answer is fine for standards purposes. However, just as an implementation observation, the test case is likely to work anyway since a polymorphic dummy argument will trigger a pass-by-descriptor, and the shape information is likely to be available in the descriptor. Van Snyder's No vote on F08/0067: Interpretation f08/0067 is unnecessary, since the ultimate reason for it is that the processor requires but doesn't know the shape of the dummy argument. There is already a requirement that an assumed-size array not appear in a context that requires its shape (5.3.8.5p4). The answer should be "The program is not standard conforming. Paragraph 4 of subclause 5.3.8.5 prohibits an assumed-size array to appear in a context that requires its shape. Since a polymorphic dummy argument requires explicit interface, the dummy argument in the present example cannot be polymorphic. Therefore the procedure might need to use copy-in/copy-out argument passing. This requires the shape of the actual argument. The program would be conforming if the first argument in the reference to SUB2 were A(:N)." The edits should be "None." The category of the interpretation should be changed from "Erratum" to "Clarification." If we must have an edit, the one proposed in f08/0067 introduces a contradiction, albeit one of minor consequence. 12.5.2.4p2 reads, in part, after the edit, If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic. If the actual argument is a polymorphic assumed-size array, the dummy argument shall be polymorphic. If the actual argument is an assumed-size polymorphic coindexed object, the dummy argument is both required and prohibited to be polymorphic. Therefore an actual argument cannot be an assumed-size polymorphic coindexed object. It would be helpful to say so, if that's what we intend. Since the proposed solution intends explicit interface in the case of the actual argument being a polymorphic assumed-size dummy argument, it would be better to say so, and put slightly less-restrictive requirements on the dummy argument of the referenced procedure: ... If the actual argument is a polymorphic assumed-size array, the procedure shall have explicit interface, and the dummy argument shall be scalar or polymorphic, or have explicit shape. This allows the actual argument to be a polymorphic assumed-size coindexed object, or, if it's not a coindexed object, to be either polymorphic or monomorphic. This arcane objection assumes that it is possible for an actual argument to be a polymorphic assumed-size coindexed object. I sought and could not find a prohibition against it. I can't think of a reason why we would have prohibited it. Robert Corbett's Comment on F08/0067: I disagree with Van's reasoning. Malcolm Cohen replied to Van Snyder: It is not really not obvious that this is such a context, so adding an explicit requirement is helpful. >If we must have an edit, the one proposed in f08/0067 introduces a >contradiction, albeit one of minor consequence. It introduces no contradiction. >This arcane objection assumes that it is possible for an actual >argument to be a polymorphic assumed-size coindexed object. I sought >and could not find a prohibition against it. I can't think of a >reason why we would have prohibited it. C615 (R612) If appears and is an array, shall appear. So it is impossible to have an assumed-size coindexed object. result of ballot on F08/0067 No change will be made as a result of these comments => F08/0067 passes unchanged. F08/0068 Pointer association and extended type arrays John Reid's Comment on F08/0068: The revised wording is hard to read and perhaps ambiguous because of the use of the indefinite article. Also, for a nonpolymorphic variable, we do not usually talk about its "declared type part". For the first edit I suggest appending to the present sentence "unless the actual argument is polymorphic and the dummy argument is not, in which case the dummy argument becomes argument associated with the declared type part of that target". A similar change can be made for the second edit. Van Snyder's Comment on F08/0068: "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. Malcolm Cohen replied to Van Snyder: Well, "a declared type part of that target" might be ambiguous, but it says "the declared type part of that target" and this cannot be ambiguous. > "Declared type" of what? (Also see F08/0069.) The target or the > pointer? This is "a pointer actual argument that is pointer associated with a target", so it can be nothing other than the declared type of the pointer actual argument. Roughly speaking, Declared Type is a concept that applies to names and expressions, and the target does not appear here (except indirectly via pointer association), so the declared type in question must be that of the pointer. > Does "part" include the possibility of a component > having the same declared type (whatever that means)? No. That would be "a component with the same type as the declared type of the actual argument". It is not "the declared type part of the actual argument". I do not agree that there is any ambiguity. We could put in lots more words, but apart from extra chances to get it wrong, and more ink, that would achieve little. result of ballot on F08/0066 /INTERP agrees that the wording can be improved => F08/0066 passes as amended. ************************************************************************ F08/0070 Finalization of INTENT(OUT) arguments Van Snyder's Comment on F08/0070: 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 [12.5.2.4p17] 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 interp. result of ballot on F08/0070 The edit will be modified to better specify where it applies => F08/0070 passes as amended. F08/0071 Vector subscript target John Reid's No vote on F08/0071: The first edit modifies text that was removed by Corrigendum 1. Van Snyder's Comment on F08/0071: 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. result of ballot on F08/0071 /INTERP agrees that more work is needed on the edits => F08/0071 fails. F08/0073 Polymorphic auto-targetting Bill Long's Comment for F08/0073: The edit at [295:16-17] in F08/0059 makes the edit in this interp unnecessary. John Reid's No vote on F08/0073: No edit is needed in view of the edit of F08/0059. result of ballot on F08/0073 /INTERP agrees that if F08/0059 passes and is published with its current edits, no edit will be needed here; a note to this effect will be added to the edits section => F08/0073 passes as amended. ---------------------------------------------------------------------- NUMBER: F03/0017 TITLE: Dummy procedure pointers and PRESENT KEYWORDS: Dummy argument, procedure pointer, PRESENT DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the Fortran standard? procedure(real), pointer :: F => null() call s ( f ) contains subroutine S ( F ) procedure(real), optional, pointer :: F print *, present(f) end subroutine S end In the Fortran 2003 standard (ISO/IEC 1539-1:2004), the second paragraph of 12.4.1.3 requires that if the dummy argument does not have the POINTER attribute and the actual argument does, the actual argument shall be associated. It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute. ANSWER: The program is standard-conforming. The Fortran 2008 standard states "Except in references to intrinsic inquiry functions, a pointer actual argument that corresponds to a nonoptional nonpointer dummy argument shall be pointer associated with a target." (12.5.2.3 paragraph 1). Since PRESENT is an intrinsic inquiry function, there is therefore no requirement on its actual argument that if it is a pointer it shall be associated. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 04-402 m170 F03/0017 submitted 04-402r2 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 11-213 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0018 TITLE: Multiple identical specific procedures in type-bound generic KEYWORDS: Type-bound generic DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: Q1. Does the following program unit conform to the Fortran standard? module M1 type T integer x contains procedure :: MyAdd_t => myadd generic :: operator(+) => myAdd_t end type T type X real q contains procedure, pass(b) :: MyAdd_x => myadd generic :: operator(+) => myAdd_x end type X contains integer function MyAdd ( A, B ) class(t), intent(in) :: A class(x), intent(in) :: B myadd = a%x + b%q end function MyAdd end module Q2. Does the following program unit conform to the Fortran standard? module M2 interface operator(+) procedure MyAdd end interface type T integer x contains procedure :: MyAdd_t => myadd generic :: operator(+) => myAdd_t end type T contains integer function MyAdd ( A, B ) class(t), intent(in) :: A real, intent(in) :: B myadd = a%x + b end function MyAdd end module Q3. If the interface block and type definition are exchanged in question 2, does the program unit conform to the Fortran standard? ANSWER: A1. The program unit is not standard-conforming. Generic operator (+) has two ambiguous specific bindings, one to myadd_t the other to myadd_x. A2. The program unit is not standard-conforming. Generic operator (+) has two ambiguous specific procedures, one being the module procedure myadd the other being the type-bound procedure myadd_t. A3. The ordering of the interface block and the type definition is immaterial. EDITS to 10-007r1: None SUBMITTED BY: Van Snyder HISTORY: 04-405 m170 F03/0018 submitted 04-405r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 11-214 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0019 TITLE: Multiple identical specific procedures in generic interface blocks KEYWORDS: Type-bound generics DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Module m12 Interface g1 Subroutine s End End Interface Interface g2 Procedure s End Interface End Module Program p12 Use m12 Interface g1 ! (1) Procedure s End Interface Interface g2 ! (2) Procedure s End Interface Call g1 Call g2 End Program It is clear that the interface block marked (2) is not conforming, since it violates C1209 which says "A procedure-name shall not specify a procedure that is specified previously in any procedure-stmt in any accessible interface with the same generic identifier." However, it is not clear whether the interface block marked (1) is conforming, since s was specified previously by an interface-body not a procedure-stmt, even though both (1) and (2) attempt to do the same thing, viz create a generic interface with a duplicate specific. An even more obscure example is Module mx12 Interface g3 Subroutine s End End Interface Private s End Program px12 Use mx12 Interface g3 Subroutine s End End Interface Call g3 End Program Here there is clearly no violation of C1209 but it is not obvious whether the ambiguity rules are applied or not. ANSWER: These examples were not intended to be conforming. An edit is supplied to clarify. EDITS to 10-007r1: [281:11-12] Replace C1209 entirely by "C1209 (R1201) An in a generic interface block shall not specify a procedure that is specified previously in any accessible interface with the same generic identifier." SUBMITTED BY: Van Snyder HISTORY: 04-406 m170 F03/0019 submitted 04-406r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Failed WG5 ballot N1657 11-221 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0021 TITLE: What kind of token is a stop code? KEYWORDS: STOP, token DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The , when it is a string of s, does not appear to be specified by the standard to be any particular kind of token. Or indeed whether it is one token per or one per . The answer to these questions determines whether blanks are allowed, disallowed, or optional, in the middle of a STOP statement in free form. Consider the following statements: (1) STOP 123 (2) STOP123 (3) STOP 1 2 3 Which, if any, of these statements are standard-conforming? ANSWER: Fortran 2008 has revised the syntax of the STOP statement. The is now a scalar integer constant expression or a scalar default character constant expression. Therefore only statement (1) is standard-conforming in free form. EDITS to 10-007r1: None. SUBMITTED BY: Malcolm Cohen HISTORY: 04-416 m170 F03/0021 submitted - Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 11-212r1 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0046 TITLE: Unlimited polymorphic pointers in common blocks KEYWORDS: Unlimited polymorphic pointer, common block DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the Fortran 2008 standard? PROGRAM foo COMMON /blk1/ x CLASS(*), POINTER :: x CALL sub END PROGRAM ANSWER: No. C5100 in Fortran 2008 prohibits unlimited polymorphic pointers in common. EDITS to 10-007r1: None. SUBMITTED BY: Rob James HISTORY: 05-137 m171 F03/0046 submitted - passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-216 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C5101 in the Fortran 2008 standard states "If a common-block-object is of a derived type, it shall be a sequence type or a type with the BIND attribute and it shall have no default initialization." 2. Whether the derived types C_PTR and C_FUNPTR have the BIND attribute affects whether they are extensible. Subclause 4.5.7.1 of the Fortran 2008 standard states "A nonsequence derived type that does not have the BIND attribute is an extensible type." Are these types extensible? 3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. No, these types do not have the BIND(C) attribute. 15.3.3 does not specify that they have the BIND(C) attribute. 15.3.4 does not require them to have the BIND attribute in order to make them interoperable. 15.3.5 would require them to interoperate with a C struct if they had the BIND(C) attribute; this is absurd, since C object pointers and C function pointers are clearly not structs. Note that whether these types have default initialization is not specified by the standard, so possession of BIND(C) would not necessarily have allowed them in COMMON anyway. 2. No, these types were not intended to be extensible. It was an oversight that these types were not explicitly excluded from being extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008 standard. An edit is provided to correct this. 3. Yes, a user-defined derived type with the BIND attribute is permitted to have private components. EDITS to 10-007r1: [10-007r1:19:15-16] In 1.3.147.6, replace the definition of "extensible type" with "type that may be extended using the EXTENDS clause (4.5.7.1)". [10-007r1:4.5.7.1p1 77:3] Insert ", other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING," after "A derived type". SUBMITTED BY: John Reid HISTORY: 05-151 m171 F03/0053 submitted - Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-217r1 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0065 TITLE: Relational equivalence KEYWORDS: Relational equivalence DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Given REAL X X = ... some value ... may IF( X+3.0 .EQ. 3.0 )... be transformed into IF( X .EQ. 0.0 )... by the processor? In Fortran 2003, 7.1.8.5 Evaluation of relational intrinsic operations says "Two relational intrinsic operations are relationally equivalent if their logical values are equal for all possible values of their primaries." On a machine where addition of 3.0 to a small value is not exact, the logical values for X+3.0==3.0 are not the same as X==0.0 for all possible values of X, therefore it would seem that this transformation would not be possible. However, Note 7.22 in Fortran 2003 shows this transformation as being acceptable. ANSWER: No, the transformation is not permitted unless it gives the same answer for all possible values (of X and X+3.0). The erroneous example has been removed in Fortran 2008. EDITS to 10-007r1: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-192 m173 F03/0065 submitted 09-150 m187 Passed by J3 meeting 09-187r2 m188 Failed J3 letter ballot #18 09-155 11-222 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0084 TITLE: IEEE_SET_ROUNDING_MODE in a subroutine KEYWORDS: IEEE_ARITHMETIC DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Section 7.1.7 of the Fortran 2008 standard says that if the value of an expression can be determined before execution of the program, it is standard-conforming to use the predetermined value. Consider the subprogram SUBROUTINE S() USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES INTEGER, PARAMETER :: sp = IEEE_SELECTED_REAL_KIND(6,30) real(sp) :: X = 0.5559013_sp real(sp) :: Y = 1.2092481_sp real(sp) :: Z1, Z2 IF (IEEE_SUPPORT_ROUNDING(IEEE_NEAREST,X) .AND. & IEEE_SUPPORT_ROUNDING(IEEE_UP,X)) THEN CALL IEEE_SET_ROUNDING_MODE(IEEE_UP) Z1 = X*Y CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST) Z2 = X*Y PRINT *, 'Residual: ', Z1 - Z2 ENDIF END (1) Is a processor permitted always to print zero for the residual Z1 - Z2 ? (2) Same question, after giving X and Y the PARAMETER attribute. ANSWER: (1) Yes. The processor is allowed to evaluate expressions (constant or otherwise) in any mathematically equivalent way. In particular, it is permitted to evaluate using higher precision than any precision available when the program is executed. For example, it might compute Z1 == Z2 == 0.67222259081253, then compute Z1 - Z2 == 0.0, regardless of how the program might do rounding at the seventh decimal digit when it is executed. (2) Yes, for the same reasons as question (1). EDITS to 10-007r1: None. SUBMITTED BY: Michael Ingrassia HISTORY: 06-372 m178 F03/0084 submitted 11-218 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r1 m198 Passed as amended by J3 letter ballot #25 ---------------------------------------------------------------------- NUMBER: F03/0096 TITLE: Can a read statement change the unit value? KEYWORDS: Read statement, unit value DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is it allowed to change the value of a variable which supplies the unit number to a read statement? 10-007 [243:3-5] says the value of any input/output specifier shall not depend on any input-item. UNIT= is a specifier in a READ statement. Note 9.40 on page 221 gives the example READ(N) N, X(N) and discusses how the changes to N work. ANSWER: Yes, the example was intended to be allowed as long as N is not an internal unit. Edits will limit the restriction to "output items" in the specifier list and the Format. EDITS to 10-007r1: In 9.12, paragraph 5, [243:3-4] Delete "on any , , or", Making that sentence read: "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." [243:5] Append new sentence to paragraph "The value of an or of a FMT=, ID=, IOMSG=, IOSTAT= or SIZE= specifier shall not depend on the values of any or in the same statement." SUBMITTED BY: Dick Hendrickson HISTORY: 07-266 m181 F03/0096 submitted 07-266r1 m181 Draft answer - withdrawn, no reason, no vote 10-246 m193 Draft answer for F2008 10-246r1 m193 Revised edit - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 m196 Failed WG5 ballot 1 N1876 11-257 m196 Revised edit 11-257r1 m196 Revised edit 11-257r2 m196 Revised edit 12-135 m197 Revised edits - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0103 TITLE: Restrictions on dummy arguments not present for polymorphic type or parameterized derived type KEYWORDS: dummy argument, present, polymorphic, parameterized derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Type t Real x End Type ... Subroutine s(x) Class(t),Optional :: x If (.Not.Present(x)) Call s2(x) End Subroutine Subroutine s2(y) Type(t),Optional :: y If (Present(y)) Print *,y End Subroutine Q1. Is the reference to s2, passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy, standard conforming? Consider Type pdt(n) Integer,Len :: n Real x(n) End Type ... Subroutine s3(y) Type(pdt(*)),Optional :: y If (.Not.Present(y)) Call s4(y) End Subroutine Subroutine s4(z) Type(pdt(10)),Optional :: z If (Present(z)) Print *,z%x End Subroutine Q2. Is the reference to s4, passing an optional dummy argument with an assumed type parameter to an optional dummy argument with a non- assumed type parameter, standard conforming? Note that 12.5.2.4 paragraph 3 requires the length type parameter values to be the same (with no mention of argument presence). One might conjecture that these should not be conforming because the argument passing conventions between s and s2, and between s3 and s4, might be different (descriptor vs. reference). DISCUSSION: This does not seem to be limited to derived types, for example: Subroutine s3(y) Character(*),Optional :: y If (.Not.Present(y)) Call s4(y) End Subroutine Subroutine s4(z) Character(10),Optional :: z If (Present(z)) Print *,z End Subroutine ? ANSWER: These were all intended to be standard-conforming. An edit is supplied to correct the type parameter matching requirements. EDITS to 10-007r1: [293:6] 12.5.2.4, beginning of paragraph 3, insert new sentence "The kind type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument." and change "The type parameter values of the actual argument" to "The length type parameter values of a present actual argument". [293:10] 12.5.2.4, paragraph 4, before "scalar" insert "present". SUBMITTED BY: Jim Xia HISTORY: 07-298r1 m182 F03/0103 submitted 07-298r2 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot #15 08-101 11-223 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0116 TITLE: indistinguishable specifics for a generic interface with use association KEYWORDS: GENERIC RESOLUTION USE ASSOCIATION DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot Consider the following program MODULE M1 INTERFACE SUBR MODULE PROCEDURE SUBR1 END INTERFACE CONTAINS SUBROUTINE SUBR1 END SUBROUTINE END MODULE M2 INTERFACE SUBR MODULE PROCEDURE SUBR2 END INTERFACE CONTAINS SUBROUTINE SUBR2 END SUBROUTINE END PROGRAM MAIN USE M1 CALL S CONTAINS SUBROUTINE S USE M2 CALL SUBR END SUBROUTINE END Is this program standard conforming? ANSWER: Subclause 12.4.3.4.5 of the Fortran 2008 standard forbids the presence of such conflicting interfaces. The rules in subclause 12.5.5.2 would be able to resolve the reference to SUBR in the example, but this fact does not negate the prohibition in subclause 12.4.3.4.5. EDITS to 10-007r1: None. SUBMITTED BY: Robert Corbett and Michael Ingrassia HISTORY: 08-169 m184 F03/0116 submitted 11-219r1 m195 Revised answer - Passed by J3 meeting 11-241 m196 Passed by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0118 TITLE: Are lower bounds of assumed-shape arrays assumed? KEYWORDS: LBOUND, assumed-shape array, constant expression DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Does the following program conform to the 2008 Fortran standard? subroutine S ( A ) integer :: A(:,3:) integer, parameter :: R = size(lbound(A)) end subroutine S Processors disagree. If the lower bounds of an assumed-shape array are assumed, LBOUND(A) is not a constant expression according to item (4)(b)(i) in subclause 7.1.12. If the lower bounds of an assumed-shape array are not assumed, LBOUND(A) is a constant expression in this case, but might be a specification expression in other cases. ANSWER: This program conforms to the 2008 Fortran standard. The lower bounds of an assumed-shape array are not assumed. If a lower bound is not specified, it has the value 1 -- see the final sentence of the final paragraph of subclause 5.3.8.3. If a lower bound is specified, it must be specified either by a constant expression or a specification expression. In the example in the question, the lower bound of the first dimension is omitted, and therefore has the value 1, while the lower bound of the second dimension is given by a constant expression. Therefore, the reference to LBOUND is a constant expression, and thus the reference to SIZE is a constant expression. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 08-200r1 m185 F03/0118 submitted 11-215 m195 Revised for F08 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r1 m198 Passed by J3 letter ballot #25 12-147 --------------------------------------------------------------------- NUMBER: F03/0120 TITLE: When are parameterized sequence types the same type? KEYWORDS: type parameter, sequence type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: (1) What does 4.5.2.4 mean by the phrase "have type parameters and components that agree in order, name, and attributes?" Does REAL A(2*N) "agree" with REAL A(N+N) ? Does REAL A(N*N) "agree" with REAL A(N**2) ? (2) How complicated can the expressions a processor must determine are equal or different be? DISCUSSION: The Fortran 2008 standard allows sequence types to have type parameters (4.5.2, 4.5.2.3). The Fortran 2008 standard also gives rules for deciding when two entities declared with reference to derived-type definitions have the same type (4.5.2.4). Those rules break down for parameterized sequence types. Although the Fortran 2008 standard does not explicitly say it, the standard assumes that two attributes that include one or more expressions agree only if the values of those expressions are the same. Previous standards used attributes with expressions that could not be evaluated statically only in contexts where the processor was not required to determine if those attributes agreed. The inclusion of parameterized sequence types has created situations where it is necessary for the processor to determine if such attributes agree. QUESTION: (3) Consider the modules MODULE M1 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(4)) :: X END MODULE M2 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(4)) :: Y END Are the variables X and Y in this example of the same type? (4) What if the two instances of the type parameter N in the previous example were not kind type parameters? (5) Consider the modules MODULE M1 INTERFACE S SUBROUTINE S1(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(2)) :: X END MODULE M2 INTERFACE S SUBROUTINE S2(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(2)) :: X END If these two modules are used in the same scoping unit and there is a CALL of the generic subroutine S in that scoping unit, does the Fortran 2008 standard require a conforming processor to detect and report the conflict with the rules given in 12.4.3.4.5? It seems it might or might not depending on one's interpretation of item (6) in 1.5. DISCUSSION: Some have suggested that two attributes that include expressions should be said to agree if and only if the corresponding expressions are equivalent. One problem with that notion is that in general the question of whether two expressions are equivalent is undecidable. That problem could be circumvented by restricting the forms of expressions allowed. For example, the expressions might be restricted to be polynomials of one or more variables. In that case, the problem of determining equivalence is merely intractable, not impossible. Some have suggested that the notion of requiring only that the values agree should be maintained. One consequence of that would be that some constraint violations that are can currently be detected statically could only be detected dynamically. For example, consider the program MODULE M1 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N+N) END TYPE END MODULE M2 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N*N) END TYPE END SUBROUTINE S(N) USE M1, T1=>T USE M2, T2=>T TYPE(T1(N)) :: X TYPE(T2(N)) :: Y Y%A = 0.0 X = Y END PROGRAM MAIN READ *, N CALL S(N) END Under the interpretation requiring equal values, the question of whether the processor must detect and report a constraint violation in the assignment X = Y cannot be determined until the value of N is known. Another suggestion was that attributes that include expressions agree if and only if they are textually equivalent. That opens up the question of what it means to say that two expressions are textually equivalent. Does whitespace count? Is "2" textually equivalent to "02"? It "2" textually equivalent to a named constant "TWO" whose value is two? Another suggestion was that two entities declared with reference to derived-type definitions in different scoping units should be considered to be of different if either or both of the derived-type definitions include type parameters. At least that solution is easy to specify. Parameterized sequence types add so little value to the Fortran language that they cannot be worth the trouble they cause for the language specification, for implementors, and, if there are any users, for users. Therefore, I suggest banning parameterized sequence types from the language. Implementations that currently support parameterized sequence types can continue to support them due to the permissive nature of the Fortran standard. ANSWER: It was not intended that parameterized derived types participate in the algorithm for determining when two types are the same, as given in section 4.5.2.4. Therefore the answers to the questions are: Not Applicable, Not Applicable, No, Still No, and No. To make this effective, edits are supplied which ban parameterized sequence types from the language. EDITS to 10-007r1: [24:11+] Append new paragraph to 1.6.2 Fortran 2003 compatibility "Fortran 2003 permitted a sequence type to have type parameters; that is not permitted by this part of ISO/IEC 1539." [62:19] 4.5.2.3 Sequence type, Replace constraint C436 with "C436 (R425) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type or of a sequence type, the derived type shall not have type parameters, and a shall not appear." [63:9] 4.5.2.4 Determination of derived types, paragraph 2, delete the phrase "type parameters and". SUBMITTED BY: Robert Corbett HISTORY: 08-261 m185 F03/0120 submitted 11-224 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 11-255 m196 Revised answer 11-255r1 m196 Passed by J3 meeting 12-132 m197 Revised edits - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F03/0121 TITLE: Precise FP semantics of the REAL intrinsic KEYWORDS: REAL intrinsic DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Must the intrinsic function REAL with KIND parameter wp return a value that is a REAL (KIND=wp) floating point number? RATIONALE FOR THE QUESTION: Computer hardware may use a wider floating-point format for registers than for memory; e.g., 80 bits for registers and 64 bits for memory for the case of standard double precision floating point numbers. Some algorithms require a high level of control over floating point semantics. If the intrinsic function REAL with KIND parameter wp is guaranteed to return a REAL (KIND=wp) result then a programmer can use this to force intermediate results into main memory format, never mind that the optimizing compiler may have placed the intermediate in a register. I am interested in a J3 interpretation of this matter, especially a loud and clear affirmative interpretation, because it appears that some present Fortran compilers optimize away my explicit use of the REAL intrinsic. The context is code for compensated summation (Kahan summation). I appreciate that parentheses are inviolable courtesy of the Fortran standard, but in order to have code that cannot be broken by an optimizing compiler I seem to need also a language mechanism to force intermediate results into main memory format. Bas Braams Chemistry Department and Emerson Center for Scientific Computation Emory University Atlanta, GA ANSWER: Yes, for purposes of determining the type and kind of the result, for use in subclause 7.1.9.3, the result of the intrinsic function REAL with KIND argument wp returns a value that is of type REAL(KIND=wp). However, if it is used within an expression involving intrinsic operations, "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated." and "mathematically equivalent expressions of numeric type may produce different computational results", which means that it is unlikely to serve your purpose. Intermediate results can be rounded to storage format by assignment to a VOLATILE variable. EDITS to 10-007r1: None. HISTORY: 08-208r1 m185 F03/0121 submitted 10-240 m193 Draft answer for F2008 - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 N1878 m186 Failed WG5 ballot 1 N1876 11-260 m196 Revised answer 11-260r1 m196 Passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0004 TITLE: Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? KEYWORDS: TARGET argument of ASSOCIATED DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is the following conforming, and if so what does it print? program TARGET_Arg integer, pointer :: Pointer integer, pointer :: Target => NULL() integer, target :: AnotherTarget pointer => anotherTarget print *, Associated(pointer,target) end program TARGET_Arg DISCUSSION: Subclause 13.7 stipulates that descriptions of arguments of intrinsic procedures apply to actual arguments. This leaves open the question whether the TARGET dummy argument of ASSOCIATED is a pointer or not. If not a pointer, being optional, it is considered by subclause 12.5.2.12 to be absent if the corresponding actual argument is disassociated. Thereby, the result value of ASSOCIATED (by Case(i) of the result value clause) is true. If the TARGET dummy argument is a pointer, the result value of ASSOCIATED (by Case (iv) of the result value clause) is false. ANSWER: The Result Value paragraph of 13.7.16 ASSOCIATED only makes sense if the references to TARGET are talking about the actual argument. Therefore the program is standard conforming and prints F. An edit is supplied to remind the reader. NOTE: This subsumes interp F08/0005 (10-152). EDITS to 10-007r1: [330:36+] Insert new Note "NOTE 13.8a The references to TARGET in the above cases are referring to properties that might be possessed by the actual argument, so the case of TARGET being a disassociated pointer will be covered by case (iii), (vi), or (vii).". SUBMITTED BY: Van Snyder HISTORY: 10-149 m192 F08/0004 submitted 10-149r1 m192 revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 m197 Failed WG5 ballot 1 N1876 12-138 m197 Revised edits - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ------------------------------------------------------------------------ NUMBER: F08/0008 TITLE: IEEE exceptions for intrinsic functions KEYWORDS: IEEE_INVALID, SQRT DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTIONS: Section 13.7.1, page 325, lines 10-12 states If an infinite result is returned, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal; if a NaN result is returned, the flag IEEE_INVALID shall signal. Question (1): The Fortran 2008 standard does not require a standard-conforming processor to support IEEE_INVALID [14.3p8, 404:15]. If a processor does not support IEEE_INVALID, is it required to signal IEEE_INVALID when a NaN result is returned? Question (2): IEC 60559 requires the result of SQRT(+inf) to be +inf without overflow being signaled. IEC 60559 requires SQRT(qNaN), where qNaN is a quiet NaN, not to signal an invalid operand exception. Does Fortran 2008 require SQRT(QNaN) to signal IEEE_INVALID? ANSWERS: A1. No, if the processor does not support IEEE_INVALID, it cannot signal IEEE_INVALID. An edit is provided to clarify this. A2. No, the standard does not specify the behavior of SQRT on qNaN. EDITS to 10-007r1: [325:7] Change "is prohibited from invoking" to "shall not invoke". {Simpler wording is easier to understand.} [325:7-8] "returned in" -> "assigned to". {Correct wording instead of nonsense.} [325:8] After "or" insert "returned as a". {Continue correcting grammar.} [325:8-12] Replace "outside ... invoked" with "not representable by objects of the specified type and type parameters". [325:12+] Insert new paragraph "If an IEEE infinity is assigned or returned by an intrinsic procedure, the intrinsic module IEEE_ARITHMETIC is accessible, and the actual arguments were finite numbers, the flag IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO shall signal. If an IEEE NaN is assigned or returned, the actual arguments were finite numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. If no IEEE infinity or NaN is assigned or returned, these flags shall have the same status as when the intrinsic procedure was invoked." SUBMITTED BY: Robert Corbett HISTORY: 10-155 m192 F08/0008 submitted 10-155r1 m192 Fix title 10-155r2 m192 Draft answer 10-155r3 m192 Revised answer - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 N1878 m197 Failed WG5 ballot 1 N1876 12-144 m197 Attempt to fix 13.7.1 12-144r1 m197 Passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25 ------------------------------------------------------------------------ NUMBER: F08/0031 TITLE: PURE INTENT(OUT) finalization KEYWORDS: PURE INTENT(OUT) FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider MODULE m TYPE t ... CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x ... fcount = fcount + 1 END SUBROUTINE PURE SUBROUTINE zap(x) ! (1) TYPE(t),INTENT(OUT) :: x END SUBROUTINE PURE SUBROUTINE bad(y) TYPE(t),INTENT(INOUT) :: y CALL zap(y) ! (2) END SUBROUTINE END MODULE Clearly, even though subroutine zap is pure, invoking it causes impure final subroutine f to be called and so therefore it cannot be invoked in any context that requires it to be pure. Thus the call marked (2) is invalid. The question is whether the subroutine definition itself (marked (1)) is standard-conforming. If finalization of INTENT(OUT) arguments is considered to be done by the called procedure, then the subroutine definition is not standard-conforming. If finalization of INTENT(OUT) arguments is done by the caller, the subroutine definition might be standard-conforming. It would certainly seem a bit strange to be able to define a PURE procedure that cannot be invoked anywhere purity is required. DISCUSSION: Although the phrase "When a procedure is invoked" sounds like finalization occurs in the caller of a procedure and not in the called procedure, being PURE or having a finalizable INTENT(OUT) dummy argument are not grounds for an explicit interface to be required. This would appear to require, as a matter of practicality, that the processor performs the finalization of the actual argument on entry to the called procedure. I.e., that the impure final subroutine will in actuality be called from the pure procedure. ANSWER: Allowing a PURE procedure to cause invocation of impure final procedures in this way was inadvertant. An edit is supplied to clarify that any INTENT(OUT) dummy arguments of a PURE procedure must not have a relevant impure FINAL procedure. EDITS to 10-007r1: [312:21+] In 12.7 after C1277, insert new constraint "C1277a An INTENT(OUT) argument of a pure procedure shall not be such that finalization of the actual argument would reference an impure procedure." {In some other constraints we use "procedure that is not pure", but "impure procedure" is a simpler way of saying the same thing.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-181 m192 F08/0031 submitted 10-181r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-142 m197 Removed J3 note, no other changes - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ------------------------------------------------------------------------ NUMBER: F08/0032 TITLE: PURE FUNCTION result finalization KEYWORDS: PURE FUNCTION FINAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider MODULE m TYPE t REAL c CONTAINS FINAL f END TYPE INTEGER :: fcount = 0 CONTAINS SUBROUTINE f(x) TYPE(t),INTENT(INOUT) :: x x%c = 0 fcount = fcount + 1 END SUBROUTINE PURE TYPE(t) FUNCTION g(a) REAL,INTENT(IN) :: a g%c = a END FUNCTION END MODULE Even though this function is PURE, invoking it will inevitably result in the execution of the impure FINAL subroutine f. Thus, it cannot be used within another PURE procedure or from within a DO CONCURRENT loop, though it can be used from within a FORALL (because the finalizations only get done on termination of the outermost FORALL). Some other cases of impure finalization are prohibited by C1284, but not this because it does not occur "in" the procedure. Should an impurely-finalizable function result be allowed for a pure function? ANSWER: No, this should not be allowed. An edit is supplied to correct this oversight in the requirements for pure procedures. EDITS to 10-007r1 (as modified by corrigendum 1): [24:11+] 1.6.2 at end of subclause insert new paragraph: "Fortran 2003 permitted the result variable of a pure function to be a polymorphic allocatable variable, or to be finalizable by an impure final subroutine. These are not permitted by this part of ISO/IEC 1539." [312:19+] In 12.7 after C1276, insert new constraints "C1276a The result variable of a pure function shall not be such that finalization of a reference to the function would reference an impure procedure. C1276b A pure function shall not have a polymorphic allocatable result variable." SUBMITTED BY: Malcolm Cohen HISTORY: 10-182 m192 F08/0032 Submitted 10-182r1 m192 Revised - Passed by J3 meeting 10-202 m192 Passed as amended by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-134 m197 Revised edits - passed byJ3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ------------------------------------------------------------------------ NUMBER: F08/0038 TITLE: Are pointless restrictions on DIM arguments intended? KEYWORDS: DIM argument, optional, intrinsic reduction function DEFECT TYPE: Clarification STATUS: Passed by J3 meeting DISCUSSION: Some of the reduction functions have two forms, one with a DIM argument and one without; the DIM argument is not optional. IALL is an example. Other reduction functions have a DIM argument that is optional. COUNT is an example. The actual argument corresponding to the DIM actual argument is prohibited from being an optional dummy argument in both cases. The reason in the case of an optional DIM argument is so that the processor can determine the rank of the result. In the case of those with two forms, there is no problem for the processor to determine the rank, so the prohibition against the corresponding actual argument being an optional dummy argument is pointless. There is already a prohibition against it being an absent optional dummy argument in 12.5.2.12p3(4) [299]. Consider, for example subroutine S ( ARRAY, DIM ) integer, intent(in) :: ARRAY(:,:) integer, intent(in), optional :: DIM if ( present(dim) ) then print *, iall(array,dim) else print *, iall(array) end if end subroutine S This subroutine clearly does not conform, but a processor would have no difficulty determining the rank of the result of IALL(ARRAY,DIM). QUESTION: (1) Was the pointless restriction intentional, or was it an oversight that it did not get removed in the two-form case when MAXLOC etc. were added? (2) Is it necessary to continue the pointless restriction? ANSWER: (1) Yes, this was intentional. These could have been removed in Fortran 95, Fortran 2003, or Fortran 2008, but there was no request for removal. (2) No, but it is inappropriate to provide a new feature that would need many edits via the defect processing system. If this feature is desired it can be added in a future revision of the language. EDITS to 10-007r1: None. SUBMITTED BY: Van Snyder HISTORY: 10-187r1 m192 F08/0038 submitted 10-187r2 m192 Revised edit - Passed by J3 meeting 10-202 m192 Passed by J3 letter ballot #21 10-199 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-133 m197 Revised answer - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ------------------------------------------------------------------------ NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: Yes. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray, therefore MOVE_ALLOC needs to be an image control statement. Also, the corank of FROM and TO needs to be the same. Edits are supplied to correct this. EDITS to 10-007r1: [188:23+] In 8.5.1 Image control statements, paragraph 2, insert new bullet point before the STOP statement one, "- a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC with coarray arguments;" [372:19] In 13.7.118p3 MOVE_ALLOC, TO argument, After "same rank" insert "and corank". SUBMITTED BY: John Reid HISTORY: 10-200 m193 F08/0040 submitted 10-200r1 m193 Answer edited - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-139 m197 Revised answer - passed J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0042 TITLE: SOURCE= questions KEYWORDS: ALLOCATE, SOURCE= DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program PROGRAM example1 REAL,ALLOCATABLE :: x(:),y(:) ALLOCATE(x(10),y(10),SOURCE=3.14159265) PRINT *,x,y END This program does not conform to Fortran 2003 due to constraint C631 which stated "If SOURCE= appears, ... shall contain only one ...". The corresponding constraint in Fortran 2008, C638 [127], is missing this requirement, so apparently the program is now syntactically correct. However, the Introduction to the Fortran 2008 standard does not mention this as a new feature. Furthermore, 6.7.1.1 paragraph 4 [127] begins "If is a coarray, shall not have a dynamic type of ..." which implies that there is only one for a (at least when the is a coarray). Similarly, the wording of constraint C639 implies a one-to-one correspondence between and . Q1. Is the omission of the single allocation requirement of Fortran 2003 an oversight? (i.e. is example1 non-conforming?). Also, consider the program PROGRAM example2 REAL,ALLOCATABLE :: x[:] ALLOCATE(x[*]) x = 3 END The ALLOCATE statement appears not to conform to Fortran 2008 because of 6.7.1.1 paragraph 4; since does not appear, it cannot satisfy any condition about its dynamic type. Q2. Is an ALLOCATE statement for a coarray required to have SOURCE=? (i.e. is example2 non-conforming?). Also, if multiple allocations with SOURCE= are permitted, consider the program PROGRAM example3 INTEGER,ALLOCATABLE :: x,y ALLOCATE(x,y,SOURCE=f()) PRINT *,x,y CONTAINS INTEGER FUNCTION f() INTEGER,SAVE :: n = 1 f = n n = n + 1 END FUNCTION END PROGRAM The execution semantics of SOURCE= in 6.7.1.2 paragraph 7 do not state whether the is evaluated once per statement or once per allocation. If the processor evaluates per statement execution, something like " 1 1" will be printed, but if it evaluates it per allocation, something like " 1 2" could be printed. Q3. How many times may be evaluated in an ALLOCATE statement with multiple allocations? Also, consider the program PROGRAM example4 REAL,ALLOCATABLE :: x(:) ALLOCATE(x,SOURCE=[0.5,1.5]) PRINT *,x END PROGRAM The Introduction implies that this program should be standard- conforming, but it violates constraint C633, which begins "(R631) If is an array either shall appear or shall appear ..." The requirements of C633 are not satisfied because R631 is and does not appear in R631. Q4. Is example4 intended to be standard-conforming? ANSWER: The answer to question 1 is No. This feature was deliberately added to the Fortran 2008 standard. Edits are supplied to correct its exposition. The answer to question 2 is No. An edit is supplied to correct paragraph 4 of 6.7.1.1. The answer to question 3 is once. An edit is supplied to clarify paragraph 7 of 6.7.1.2. The answer to question 4 is Yes. An edit is supplied to correct constraint C633. EDITS to 10-007r1: [xv] Introduction, bullet "Data usage and computation", Before "MOLD=" Insert "Multiple allocations are permitted in a single ALLOCATE statement with SOURCE=." {(Q1) Add new feature to the feature list.} [126:31-33] Replace C633 entirely with the constraints "C633 (R626) If an is an array, either shall appear in its , or shall appear in the ALLOCATE statement and have the same rank as the . C633a (R631) If is scalar, shall not appear." {(Q4) Fix broken constraint.} [127:5] Constraint C639, replace entirely with "C639 (R626) If appears, the kind type parameters of each shall have the same values as the corresponding type parameters of ." {(Q1) Fix singular implication. Avoid introducing any implication that each has the same set of kind type parameters or that any has the same set of kind type parameters as the - the relationship is a subset.} [127:18-19] 6.7.1.1 paragraph 4, replace entirely with "If an is a coarray, the ALLOCATE statement shall not have a with a dynamic type of C_PTR, C_FUNPTR, or LOCK_TYPE, or which has a subcomponent whose dynamic type is LOCK_TYPE." {(Q2) Fix implied requirement of SOURCE= appearance for coarrays.} [128:26] 6.7.1.2 paragraph 7, append new sentence "The is evaluated exactly once for each execution of an ALLOCATE statement." {(Q3) Clarify number of evaluations.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-211 m193 F08/0042 submitted - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-140 m197 Revised Q2 and edits - passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25. ---------------------------------------------------------------------- NUMBER: F08/0043 TITLE: Executing a type-bound procedure on a coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Consider the following program: module m type :: foo integer :: i = 0 contains procedure, pass :: op end type contains subroutine op(this, i) class(foo) :: this this%i = i end subroutine end module m program p use m class(foo), allocatable :: o_foo[:] integer :: me allocate(foo :: o_foo[*]) me = this_image() if (me == 1) then call o_foo[2]%op(1) ! Type-bound call. end if sync all if (me == 2) write(*,*) o_foo%i end program p This program is not standard-conforming, as it violates one of the requirements of 12.5.2.4p2 [293], viz "If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic." However, if the type-bound call were replaced by SELECT TYPE(o_foo) TYPE IS (foo) CALL o_foo[2]%op(1) END SELECT appears to be standard-conforming. The example program appears to be harmless, so the requirement appears to be unnecessary. It is conjectured that the requirement is misworded and should instead be "If the actual argument is a polymorphic subobject of a coindexed object, the dummy argument shall not be polymorphic."? Q1. Is this requirement intentional? Furthermore, constraint C1229 says of a that is the object for a type-bound procedure reference, that it "shall not be a polymorphic subobject of a coindexed object"; however, C617 already prohibits any from being a polymorphic subobject of a coindexed object except as the subject of a type parameter inquiry or as the actual argument in an intrinsic inquiry function reference, so C1229 appears to be completely redundant. Q2. Is constraint C1229 redundant? ANSWER: A1. The requirement is intentional. A2. Yes, constraint C1229 is redundant. It will be removed in a future revision. EDITS to 10-007: None. SUBMITTED BY: R. Bader HISTORY: 10-208 m193 F08/0043 submitted 10-208r1 m193 Revised - Passed by J3 meeting 11-129 m194 Passed by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed Wg5 ballot 2 N1877 12-143 m197 Removed attempt to explain the rationale - passed by J3 meeting 12-157r1 m198 Passed as amended by J3 letter ballot #25 ---------------------------------------------------------------------- NUMBER: F08/0048 TITLE: Sequence association for coarrays KEYWORDS: sequence association, coarrays DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Was the text in 12.5.2.8: "If the dummy argument is an array coarray that has the CONTIGUOUS attribute or is not of assumed shape, the corresponding actual argument shall be simply contiguous." intended to disallow sequence association for coarrays, as illustrated by the example interface subroutine sub (x) real x(10)[*] end subroutine end interface ... real :: x(100)[*] ... call sub (x(10)) ANSWER: No. This restriction contradicts 12.5.2.4 paragraph 13, which allows the example program. An edit is supplied to correct this. EDIT: In 12.5.2.8 Coarray dummy variables, at the end of paragraph 2 [297:5], add "or an element of a simply contiguous array". SUBMITTED BY: John Reid HISTORY: 10-226 m193 F08/0048 submitted 10-226r1 m193 Revised answer 10-226r2 m193 Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 12-124 m197 Changed answer - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0054 TITLE: Requirements for needing an explicit interface KEYWORDS: Explicit interface DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program SUBROUTINE Fred() BIND(C,NAME='Nurke') PRINT *,'ok' END SUBROUTINE SUBROUTINE S(dummy) INTERFACE SUBROUTINE dummy() BIND(C) END SUBROUTINE END INTERFACE CALL dummy END SUBROUTINE PROGRAM example1 EXTERNAL Fred,S CALL S(Fred) END PROGRAM According to 12.4.2.2, an explicit interface is only ever required in a scope where a procedure is referenced. The main program does not reference Fred, so this appears to be conforming. It appears that no processors accept this example... However, the very similar program minus the BIND(C) specifications SUBROUTINE Freddy(x) LOGICAL,OPTIONAL :: x IF (PRESENT(x)) PRINT *,'ok' END SUBROUTINE SUBROUTINE SUB(dummy) INTERFACE SUBROUTINE dummy(x) LOGICAL,OPTIONAL :: x END SUBROUTINE END INTERFACE CALL dummy(.TRUE.) END SUBROUTINE PROGRAM example2 EXTERNAL Freddy,SUB CALL SUB(Freddy) END PROGRAM but with a different reason for requiring an explicit interface, is also apparently valid in Fortran 2003/2008 but is not valid in Fortran 90 or Fortran 95, because they require the explicit interface without the condition of the procedure being referenced in that scope. This feature (viz only require the explicit interface where it is referenced) was added by paper 02-144, which makes no mention of it being a new feature. Was this a deliberate new feature? ANSWER: No, this was a mistake in 02-144 and thus in Fortran 2003 and 2008. An edit is provided to correct the mistake. EDITS to 10-007r1 (after corrigendum 1): [24:11+] 1.6.2 Compatibility, at the end, insert new paragraph "Fortran 2003 only required an explicit interface for a procedure that was actually referenced in the scope, not merely passed as an actual argument. This part of ISO/IEC 1539 requires an explicit interface for a procedure under the conditions listed in 12.4.2.2, regardless of whether the procedure is referenced in the scope." [279:19] In 12.4.2.2p1, replace "A procedure ... and" with "Within the scope of a procedure identifier, the procedure shall have an explicit interface if \obs{it is not a statement function and}" SUBMITTED BY: Malcolm Cohen HISTORY: 11-135 m194 F08/0054 submitted 11-135r1 m194 Passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 m197 Failed WG5 ballot 2 N1877 12-141 m197 Revised edits 12-141r1 m197 Revised edits - Passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0055 TITLE: G editing for reals KEYWORDS: format, G editing DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Q1. Gw.d editing for a real value that is in the range (0.1,10**d) and is not near an integer power of 10 uses F editing to produce exactly a value with d significant digits. For values in this range that are near an integer power of 10, is it intended that F editing be used to produce a value with d significant digits? The rules in 10.7.5.2.2 usually have this effect, but the following examples illustrate exceptions for rounding UP and to ZERO. print "(ru,g11.2)", -9.95 print "(rz,g11.2)", -9.95 When rounded to two significant digits these are both equal to -9.9, however following through the rules in the standard it says to use F7.0 format which will give the result -9. (only one significant digit). For positive values, rounding DOWN and to ZERO print "(rd,g11.2)", 9.95 print "(rz,g11.2)", 9.95 both give the result 9.9 according to the rules in the standard. Q2. Is Gw.d editing intended to use F editing when that produces d significant digits? It usually achieves this, but for print "(ru,0p,g11.2)", -99.5 the standard requires 0PE11.2 editing to be used, which gives -0.99E+02 even though F7.2 editing can represent it as -99. Similarly for print "(ru,0p,g11.2)", 99. the standard requires 0PE11.2 editing to be used, which gives 0.99E+02, even though it is representable in F7.2 format as 99. Q3. COMPATIBLE and NEAREST modes of rounding differ only when the two nearest representable values are equidistant from the given value. The similarity appears not to be represented in the second table. What is meant by "if the higher value is even"? If by "even" we mean the last digit is even, then since we are talking about a mantissa which is close to 10, COMPATIBLE and NEAREST would have the same effect. Q4. The table has no entry for PROCESSOR_DEFINED rounding; since there is no value specified for r, it is impossible to interpret the table, which seems to indicate that it would not be standard conforming to use G editing with PROCESSOR_DEFINED. How does the PROCESSOR_DEFINED I/O rounding mode affect G editing? Q5. According to 10.7.2.3.7 paragraphs 3 and 4, the effect of NEAREST is processor dependent unless IEEE rounding on conversions is supported. How does this affect G editing? Q6. Consider PRINT '(5(1X,1PG9.0))', 0.0, 0.04, 0.06, 0.4, 0.6 noting that these values are strictly monotonic increasing. The standard appears to say that the output should be 0.E+00 4.E-02 0. 0. 6.E-01 which is decidedly not monotonic increasing. Is this intentional? ANSWER: A1. Yes, it is intended to produce output with d significant digits. The algorithm for choosing the output form for some I/O rounding modes is defective. An edit is provided to replace this algorithm. A2. Yes. This is solved by the same edit. A3. This question is rendered moot by the same edit. A4. This question is rendered moot by the same edit. A5. This question is rendered moot by the same edit. A6. No. An edit is supplied to fix this. EDITS to 10-007r1: [24:11+] In 1.6.2, insert new paragraph following paragraph 1: "The form produced by the G edit descriptor for some values and some I/O rounding modes differs from that specified by Fortran 2003." [24:27+] In 1.6.3, append new bullet item "- The form produced by the G edit descriptor with d==0 differs from that specified by Fortran 95 for some values.". [25:6] In 1.6.4, replace the last full stop with semicolon and insert new bullet item "- the G edit descriptor with d==0 for some values.". [258:14-] Insert new paragraph "If \si{d} is zero, \si{k}PE\si{w}.0 or \si{k}PE\si{w}.0E\si{e} editing is used for G\si{w}.0 editing or G\si{w}.0E\si{e} editing respectively." {Without the italics markup, this is "If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee editing respectively."} [258:15-19] Replace the second and subsequent sentences of paragraph 4 including the two internal pseudo-tables by "If the internal value is a zero value, let $s$ be one. If the internal value is a number other than zero, let \it{N} be the decimal value that is the result of converting the internal value to \si{d} significant digits according to the I/O rounding mode and let $s$ be the integer such that $10^{s-1}$ <= \it{N} < $10^s$. If $s$<0 or $s$>\si{d}, \si{k}PE\si{w}.\si{d} or \si{k}PE\si{w}.\si{d}E\si{e} editing is used for G\si{w}.\si{d} editing or G\si{w}.\si{d}E\si{e} editing respectively, where \si{k} is the scale factor (10.8.5). If 0<=$s$<=\si{d}, the scale factor has no effect and F(\si{w}-\it{n}).(\si{d}-$s$),n('b') editing is used where \it{b} is a blank and \it{n} is 4 for G\si{w}.\si{d} editing and \si{e}+2 for G\si{w}.\si{d}E\si{e} editing." {Note: \it{something} is something in italics, \si{something} is a syntax term (in italics), and $something$ is LaTeX math notation. Without the italics markup, this is "If the internal value is a zero value, let s be one. If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the I/O rounding mode and let s be the integer such that 10^(s-1) <= N < 10^s. If 0<=s<=d, F(w-n).(d-s),n('b') editing is used where b is a blank and n is 4 for Gw.d editing and e+2 for Gw.dEe editing. If s<0 or s>d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively."} SUBMITTED BY: John Reid and Thomas Henlich HISTORY: 11-174 m195 F08/0055 submitted 11-174r2 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 11-261 m196 Revised edits - Passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25 ---------------------------------------------------------------------- NUMBER: F08/0056 TITLE: Non-polymorphic ALLOCATE with polymorphic SOURCE= KEYWORDS: ALLOCATE, polymorphic, SOURCE=. DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Program m195_m1 Type t Real c End Type Type,Extends(t) :: t2 Real d End Type Class(t),Allocatable :: x Type(t),Allocatable :: y Allocate(x,Source=t2(1.5,-1.5)) Allocate(y,Source=x) ! (*) ... End Program Is the second ALLOCATE statement (marked *) standard-conforming? The only requirement is that Y be type-compatible with X; they both have the same declared type so this is true. However, the very similar Allocate(y,Source=t2(1.2,-1.5)) would not be conforming because Y is not type-compatible with the structure constructor, and y = x would also not be conforming (the dynamic types being different). However, the standard says that "the value of [y] becomes that of [x]" which is clearly impossible. Since the standard fails to establish an interpretation one might conclude that the example is not conforming. However, the similar situation with the dynamic types being the same but with non-deferred length type parameters being different is explicitly stated to be conforming (and to raise an error condition), perhaps this was also intended to raise an error condition. It is also possible that the intent was to use the value of the declared type part in this case, as happens for pointer assignment. What is the interpretation of this ALLOCATE statement? ANSWER: The statement was intended to be conforming and to use the declared type part of the source-expr only. An edit is supplied to clarify. EDIT: [128:24] In 6.7.1.2p7, before "On successful", insert "If an is not polymorphic and the is polymorphic with a dynamic type that differs from its declared type, the value provided for that is the ancestor component of the that has the type of the ; otherwise, the value provided is the value of the ." [128:25-26] Replace "that of " with "the value provided", twice. SUBMITTED BY: Malcolm Cohen HISTORY: 11-194 m195 Submitted 11-194r1 m195 Revised answer = passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0057 TITLE: Interoperability with empty types. KEYWORDS: Interoperability, derived type. DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider TYPE,BIND(C) :: t END TYPE This is apparently standard-conforming, and interoperates with struct t { }; However, the latter is not valid syntax according to the C standard. How can a type be interoperable with a syntax error? ANSWER: The type definition was not intended to be standard-conforming. An edit is supplied to correct this error. EDIT: [431:11-] In 15.3.4, insert new constraint before C1505 "C1505a (R425) A derived type with the BIND attribute shall have at least one component." SUBMITTED BY: Malcolm Cohen HISTORY: 11-195 m195 F08/0057 submitted - passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25 ---------------------------------------------------------------------- NUMBER: F08/0058 TITLE: ENTRY point RESULT variable KEYWORDS: ENTRY, RESULT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: MODULE m REAL x CONTAINS FUNCTION f() f = 1 x = 2 RETURN ENTRY e() RESULT(x) x = 3 END FUNCTION END MODULE Is this standard-conforming? If so, what is the result of referencing f() and e(), and what effect does that have on the module variable x? Note that the standard prohibits dummy arguments of an entry point from appearing in executable statements ahead of the ENTRY statement (unless they are also dummy arguments of an earlier ENTRY statement or the FUNCTION statement), but makes no similar requirement on the RESULT name. ANSWER: This program was not meant to be conforming. An edit is provided to correct this mistake in the standard. EDITS to 10-007r1: Append new statement to 12.6.2.6p8 [310:20], "A name that appears as a in an ENTRY statement shall not appear in any executable statement that precedes the first RESULT clause with that name." Append new statement to 12.6.2.6p9 [310:23] "A name that appears as a in an ENTRY statement shall not appear in the expression of a statement function that precedes the first RESULT clause with that name unless the name is also a dummy argument of that statement function." SUBMITTED BY: Malcolm Cohen HISTORY: 11-196 m195 F08/0058 submitted 11-196r1 m195 Revised edits - Passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0059 TITLE: Auto-targetting requirements KEYWORDS: POINTER, TARGET, argument association DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider PROGRAM one REAL,TARGET :: x = 0 CLASS(*),POINTER :: p p => x ! (0). CALL s(p) ! (1). CALL s(x) ! (2). PRINT *,x CONTAINS SUBROUTINE s(q) CLASS(*),INTENT(IN),POINTER :: q IF (ASSOCIATED(q)) THEN SELECT TYPE (q) TYPE IS (REAL) q = q + 1 END SELECT END IF END SUBROUTINE END PROGRAM Clearly everything except statement (2) is standard-conforming. The statement marked (2) violates the requirement in 12.5.2.5 paragraph 2 for the actual argument to be polymorphic when the dummy argument is a polymorphic pointer. However, apart from that requirement, statement (2) is functionally equivalent to the sequence (0) then (1), so the "auto-targetting" feature does not need this requirement. Was this imposition of this requirement (which is needed when both the actual and the dummy are pointers) an oversight in this case? Note that similar considerations apply to CHARACTER(100),TARGET :: actual CHARACTER(:),POINTER,INTENT(IN) :: dummy in that the pointer assignment would be valid, but the requirements in 12.5.2.5 paragraph 5 are not met. ANSWER: Yes, the imposition of these requirements to the auto-targetting feature was an oversight. An edit is supplied to correct this. EDITS to 10-007r1: [295:16-17] In 12.5.2.5, Replace paragraph with "The requirements in this subclause apply to an actual argument with the ALLOCATABLE or POINTER attribute that corresponds to a dummy argument with the same attribute." {Except for paragraph 4, all these requirements are unnecessary when auto-targetting is happening. Note that 12.5.2.5p6 is moot because a coindexed object is not permitted in auto-targetting as it is not a valid target in a pointer assignment (C725).} [296:4-5] Delete paragraph 12.5.2.5p4 and reinsert twice, once at [296:12+] as a new paragraph after 12.5.2.6p3, and once at [296:35] as a new sentence at the end of 12.5.2.7p3. {Duplicate the bit about assumed type parameters.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-197 m195 F08/0059 submitted 11-197r1 m195 Revised editing instructions - Passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25 ---------------------------------------------------------------------- NUMBER: F08/0060 TITLE: Procedure pointer assignment with an EXTERNAL target. KEYWORDS: Procedure pointer, pointer assignment, EXTERNAL attribute. DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Program m5 Print *,f() Call s Contains Subroutine s Procedure(Real),Pointer :: p Print *,g() p => f ! (1) Print *,p() p => g ! (2) Print *,p() End Subroutine End Program Function f() f = 1 End Function Function g() g = 2 End Function is this program standard-conforming? On the face of it, both (1) and (2) violate constraint C729, which only allows an external procedure "that is accessed by use or host association and is referenced in the scoping unit as a procedure or that has the EXTERNAL attribute". The function f is accessed by host association but is not referenced in the scoping unit as a procedure, whereas the function g is referenced in the scoping unit as a procedure but is not accessed by use or host association. Furthermore, consider Program m5a Real,External :: f,p Pointer p p => f ! (3) Print *,p() End Program ! function f as above. Is this conforming? The constraint has a single clause for external procedures with no commas but with a disjunction and a conjunction, therefore it is ambiguous whether it means "accessed by use or host association" AND ("is referenced in the scoping unit as a procedure" OR "has the external attribute") or whether it means ("accessed by use or host association" AND "is referenced in the scoping unit as a procedure") OR "has the external attribute") Since the standard does not unambiguously give an interpretation of this program it seems that statement (3) is also not conforming. Which of these three procedure pointer assignment statements were intended to be conforming? DISCUSSION: The wording of this constraint was determined by Interp F03/0138, which intended to change it to "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association, referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." but a last-minute "editorial" change at the WG5 ballot stage made it "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association and is referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." instead, and the comma got lost in between there and Fortran 2008. Despite supposedly being an editorial change, the WG5 wording has different technical results. According to the original wording of the interp, all three examples above were intended to be allowed. ANSWER: All three pointer assignment statements were intended to be valid. An edit is supplied to correct the error in the standard. EDITS to 10-007r1: [158:33-159:2] In 7.2.2.2, C729, replace "an external ... bullet ($\bullet$)" with "a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), or an external procedure that is accessed by use or host association, referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute". {NB: $\bullet$ is the LaTeX command that produces a bullet.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-198 m195 F08/0060 submitted - Passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0061 TITLE: Description of the CONTIGUOUS attribute misworded? KEYWORDS: CONTIGUOUS DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Consider the following code: module mod_cont contains subroutine fcont(x) real, contiguous :: x(:) integer :: i x = (/ (real(i),i=1,size(x)) /) end subroutine fcont end module mod_cont program cont use mod_cont implicit none real :: x(45) call fcont(x(1::3)) end program Is this program standard conforming? 5.3.7 paragraph 1 says: "The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated with a contiguous effective argument, or that an array pointer can only be pointer associated with a contiguous target." ANSWER: Yes. The effect of the CONTIGUOUS attribute is misstated. An edit is supplied to correct this. EDITS for 10-007r1: [93:7-8] In 5.3.7p1, Change "can only be argument associated with a contiguous effective argument" to "is contiguous". SUBMITTED BY: Reinhold Bader HISTORY: 11-199r1 m195 F08/0061 submitted 11-199r1 m195 Revised edits 11-199r2 m195 Revised edits - Passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25 ---------------------------------------------------------------------- NUMBER: F08/0062 TITLE: Mixing default initialization with DATA initialization KEYWORDS: DATA, default initialization, explicit initalization DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: In the following program, one component has a default initialization and the other is initialized in a DATA statement. Is the program valid? module oad_active implicit none type active integer :: v integer :: d = 42 end type end module module tots_c use oad_active implicit none type(active), save :: trlkold data trlkold%v /100/ end module program foo use tots_c implicit none if (trlkold%d /= 42) stop 'ERROR d /= 42' if (trlkold%v /= 100) stop 'ERROR v /= 100' end program foo WG5/N1830 has [p104, 5.4.7, parag. 2] If a nonpointer object has default initialization, it shall not appear in a . and [p89, 5.2.3, parag. 1] Explicit initialization alternatively may be specified in a DATA statement unless the variable is of a derived type for which default initialization is specified. [...] A variable, or part of a variable, shall not be explicitly initialized more than once in a program. and [p70, 4.5.4.6, parag. 6] Explicit initialization in a type declaration statement (5.2) overrides default initialization ANSWER: It was intended that the data statement not be conforming. 5.4.7p2 was carefully worded to use "shall not appear" rather than "shall not be the ". The intention was that an object be initialized entirely in a type declaration statement, or that only those parts of it having default initialization be initialized. It was considered to be a burden on processors to be required to initialize some parts of a structure using default initialization, and other parts of it explicitly. EDITS to 10-007r1: None. SUBMITTED BY: Tobias Burnus HISTORY: 11-201 m195 F08/0062 submitted 11-201r1 m195 Draft answer - Passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0063 TITLE: G editing to a narrow output field KEYWORDS: G edit descriptor, narrow field, asterisks DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: What will be the output for the following program: PROGRAM MAIN PRINT '(G6.5)', 1.0 END Will it print six asterisks ("*****") or 2 followed by four blanks ("** ")? According to subclause 10.7.5.2.2, because 0.1-0.5E-6 <= 1.0 < 1E5 - 0.5 this will do F editing, and according to the table that means F2.4,4(' ') ANSWER: 10.7.2.3.2 says "the field occupies w positions, the fractional part of which consists of d digits" and this does not make sense if w x ! (1) y = t(x) ! (2) p => x( [ 1,4,9,25 ] ) ! (3) y = t(x( [ 1,4,9,25 ] )) ! (4) PRINT *,y%q END PROGRAM The pointer assignment statement at (1) associates P with X. The intrinsic assignment statement at (2) includes the effect of pointer assignment of X to Y%Q, but is not a pointer assignment statement. The pointer assignment statement at (3) is not standard-conforming according to 6.5.3.3.2 paragraph 2: "An array section with a vector subscript shall not be ... the in a pointer assignment statement" However, the intrinsic assignment statement at (4) is not subject to this requirement as it is not a pointer assignment statement. Note that the quoted paragraph is entirely duplicative, as in: - the first bullet item is covered by 12.5.2.4p18, - the second bullet item is covered by C724 in 7.2.2.2 (but C724 does not cover this case either), - the third bullet item is covered by C901 in 9.5.1. Some editorial improvements could be made. Q1. Was the statement marked (4) intended to be allowed? Q2. If not, was it intended to be prohibited by a constraint like C724, or was it intended to be a simple requirement? (Editorial note: in any case surely the requirement should appear in the pointer assignment subclause.) ANSWER: A1. No, this was not intended. An edit is supplied to correct this. A2. Constraint C724 was intended to cover this case. An edit is supplied to correct this. EDIT: [124:6] 6.5.3.3.2 Vector subscript, paragraph 2, second bullet item, Change "the in a pointer assignment statement" to "the target in pointer assignment (C724)". [158:19-20] In 7.2.2.2 Syntax of the pointer assignment statement, C724, change ""(R737) A " to "A variable that is a pointer target", making the whole constraint read: "A variable that is a pointer target shall have either the TARGET or POINTER attribute, and shall not be an array section with a vector subscript." {Make the constraint apply to all forms of pointer assignment.} EDITORIAL (for next revision): Additional edits are suggested: [124:4] Change "An" to "Note that an", change "shall not be" to "is not permitted to be". [124:5] After "redefined" insert "(12.5.2.4)". [124:7] After "file" insert "(C901)". SUBMITTED BY: Malcolm Cohen HISTORY: 12-121 m197 F08/0071 submitted 12-121r1 m197 Revised wording with same edits - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0072 TITLE: Final subroutines with corank KEYWORDS: FINAL subroutine, finalization, coarrays, codimension, corank DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is it intentional that final subroutines with coarray dummy arguments are allowed? ANSWER: No. An edit is supplied to correct this. EDITS to 10-007r1: In C480 [4.5.6.1 10-007r1:75:10] in the second sentence, add "noncoarray," before "nonpointer". SUBMITTED BY: Tobias Burnus HISTORY: 12-125 m197 F08/0072 submitted 12-125r1 m197 Revised, same answer with 10-007r1 references - passed by J3 meeting 12-165r1 m198 Passed by J3 letter ballot #25 12-147 ---------------------------------------------------------------------- NUMBER: F08/0073 TITLE: Polymorphic auto-targetting KEYWORDS: polymorphic, pointer, dummy DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider Program m013 Type t Real c End Type Type(t),Target :: x Call s(x) Print *,x%c Contains Subroutine s(p) Class(t),Pointer,Intent(In) :: p p%c = 3 End Subroutine End Program Is the invocation of S standard-conforming? According to 12.5.2.5p2, because dummy P is polymorphic, the actual argument is required to be polymorphic, even though the dummy argument is not associated with the actual argument. ANSWER: The invocation of S was intended to be standard-conforming; the polymorphism-matching requirement in 12.5.2.5 was intended to apply only when both the actual and dummy arguments were pointers (or allocatables). An edit is supplied to correct this mistake. EDITS to 10-007r1: [295:18] 12.5.2.5p2, change "The" to "Except in the case where the dummy argument is a pointer and the actual argument is not a pointer, the" Note: This edit will be completely unnecessary if interp F08/0059 passes with its current edits (or similar). SUBMITTED BY: Malcolm Cohen HISTORY: 12-131 m197 F08/0073 submitted - passed by J3 meeting 12-165r1 m198 Passed as amended by J3 letter ballot #25 ----------------------------------------------------------------------