ISO/IEC JTC1/SC22/WG5 N1847 Result of WG5 letter ballot on N1845 John Reid N1846 asked this question Please answer the following question "Is N1814 ready for forwarding to SC22 as the PDTR?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. The numbers of answers in each category were: 0 for 1) Yes. 3 for 2) Yes, but I recommend the following changes. 5 for 3) No, for the following reasons. 1 for 4) Abstain. 1 without an answer in one of these categories. Here are the responses in detail _______________________________________________________________________ Van Snyder 2) Yes, but I recommend the following changes: Mostly quibbles about wording, except for items 8 and 36, which request technical changes. 1. [Introduction, p5, line 2] Replace "require that any changes be made" by "require any changes to be made". 2. [1.1p1 1:8] Insert a comma after "C" 3. [2.1p3+ UTI TR17 3:16+] Yes. 4. [2.2p4+ UTI TR18 4:5+] Yes 5. [3.3p2 5:15-16] Should be a constraint. But... similar provisions in Clause 12 of 1539-1 are not constraints. 6. [4.1p1 7:3] Insert "subclause" before "4.2". 7. [5.2.1p1 9:9] It is not clear what base types CFI_attribute_t, CFI_index_t, CFI_rank_t and CFI_type_t have. They are simply described as "typedef". "typedef" for what? Integers, I suspect. The base type should be specified. 8. [5.2.1p3 9:19-21] Is there a good reason to prohibit a C source file from having any identifiers other than the ones gotten from ISO_Fortran_binding.h to begin with CFI_? A "google" search for "CFI" returned 6,320,000 results, so it is conceivable that a pre-existing C file might have identifiers beginning with CFI, and then someday need to be interoperable. For example, at http://www.gocfi.com we see "CFI provides Enterprise Asset Management, Computerized Maintenance Management System, Archibus, CMMS Software,...." If possible, delete this paragraph. 9. [5.2.2p1 9:23] CFI_cdesc_t is described as a "typedef" but it's not in the list of "typedef" names in 5.2.1p1. Is there a more precise C term that could be used here? I didn't know that a "typedef" had members. Is "typedef for a struct" correct? 10. [5.2.2p1 CFI_dim_t+ 10:12+] 5.2.3p3-4 concern the ordering of dimensions (5.2.3p3), or the properties of the array as a whole (5.2.3p4), not the properties of one dimension. Those paragraphs should therefore be in 5.2.2. 11. [5.2.3p1 10:14] CFI_dim_t is described as a "typedef" but it's not in the list of "typedef" names in 5.2.1p1. Is there a more precise C term that could be used here? I didn't know that a "typedef" had members. Is "typedef for a struct" correct? 12. [5.2.3p1 lower_bound 10:18] Replace "lower bound of an array for a specified dimension" by "lower Fortran bound for the dimension being described". "of an array" isn't needed because the introductory paragraph says CFI_dim_t is used to represent bounds of arrays. 13. [5.2.3p1 extent 10:19] Replace "of an array along a specified dimension" by "along the dimension being described". 14. [5.2.3p1 sm 10:21] Replace "of the array along a specified dimension" by "along the dimension being described". 15. [5.2.3p3 10:24-25] Replace "sm value" by "sm member" twice. Insert "the CFI_dim_t struct for" before "one dimension". The latter change is recommended because item 10 recommends to move this paragraph to 5.2.2. 16. [5.2.3p4 10:28-29] Replace "member attribute" by "attribute member"; replace "member extent" by "extent member"; replace "member dim" by "dim member". 17. [5.2.4p5 Table 5.1] Replace "assumed" by "assumed shape" (to distinguish from "assumed type" or "assumed rank"). Dehyphenate "assumed-size". 18. [5.2.5 13:1-17:26] Since C formal parameter names are written in lower case, it's not obvious from reading the text what is an argument name and what is an ordinary word. Either use "code font" for argument names, or the layout of the description of intrinsic functions that is used in Clause 13 of 1539-1 (or both). Constructions such as "argument dv" should be "dv argument" throughout 5.2.5. Otherwise one at first reads "argument result" or "argument attribute" or "argument type" to mean "the result of the argument" or "the attribute of the argument" or "the type of the argument". That is, "the argument type" reads too much like "the argument's type" at first glance. 19. [5.2.5.2 13:16-17] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. After "C descriptor" insert "pointed to by the dv argument". 20. [5.2.5.2p1 13:19,21] Replace "subscripts array" by "subscripts argument" twice. 21. [5.2.5.3 13:22,24-14:1] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. 21a [5.2.5.3p1 13:24-14:1] Replace "an object" by "the object described by the C descriptor pointed to by the dv argument". Replace "is not for" by "does not describe". 21b. [5.2.5.3p1 14:2,3] Replace "arrays" by "arguments" twice. 21c. [5.2.5.3p1 14:3] After "rank" insert "$r$". Before "lower_bounds" insert "first $r$ elements of the". 21d. [5.2.5.3p1 14:4] Before "bounds" insert "Fortran" twice. 21e. [5.2.5.3p1 14:8] Replace "is" by "might be" since the "is" assertion was denied twice already. 22. [5.2.5.4 14:9] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. 22a. [5.2.5.4p1 14:10] Replace "an object that was" by "the object described by the C descriptor pointed to by the dv argument. It shall have been". 22b. [5.2.5.4p1 14:16] Replace "is" by "might be" since the "is" assertion was denied twice already. 23. [5.2.5.5p1 14:19] After "establishes" insert "the dv argument to be". 23b. [5.2.5.5p3 14:28-29] Before "a C descriptor" insert "the descriptor pointed to by the dv argument to be" twice. 24. [5.2.5.5p6 14:38] What are the units of the size of an element of the object? Bytes? Whatever is returned by the C sizeof operator? 24b. [5.2.5.5p6 14:39] What are the units of the length of an element of the character object? Bytes? Characters (which might be more than one byte each)? 25. [5.2.5.5p7 14:41] Replace second "dim" by "Fortran dimension". 26. [5.2.5.6 15:27] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. 26a. [5.2.5.6p1 15:28] Insert "descriptor pointed to by the dv" before "argument". 27. [5.2.5.7p1 15:32] Replace "result" by "the result argument". 27a. [5.2.5.7p1 15:33] Replace "pointed to by source" by "described by the C descriptor pointed to by the source argument". 28. [5.2.5.7p3 15:38] Replace "and" by "; it" or ". It". 29. [5.2.5.7p5 15:42] Replace "dim information of" by "Fortran dimension information for". 30. [5.2.5.8p1 16:13] Replace "a C descriptor" by "the C descriptor pointed to by the result argument" (compare 5.2.5.7p1). 31. [5.2.5.8p1 16:13-14] This only works for one part at a time. Replace "whose elements are parts" by "for which each element is a part". Replace "The parts" by "The part". 32. [5.2.5.8p3 16:20] Replace "and" by "; it" or ". It". 33. [5.2.5.8p4 16:23] Replace "arguments displacement and elem_len" by "displacement and elem_len arguments". 34. [5.2.5.8p6 16:28] Replace "type" by "the type argument". 35. [5.2.5.9p3 17:7] Before \cf{ptr_dv} insert "the Fortran pointer described by the C descriptor pointed to by" 35a. [5.2.5.9p4 17:9] Replace "\cf{ptr_dv} C descriptor" by "C descriptor pointed to by \cf{ptr_dv}". 35b. [5.2.5.9p5 17:1] C doesn't use the term "target of". Replace "target of \cf{ptr_dv}" by "the C descriptor pointed to by \cf{ptr_dv}". 36. [5.2.8p3(2)(a) 18:28-29] Why did we go to the trouble to develop descriptors for array arguments, and then not allow (a pointer to) one as a function result? This should allow the result to have the Fortran POINTER or ALLOCATABLE attribute. The result would be a C pointer to a descriptor of type CFI_desc_t. The processor should be able to handle this with the same mechanisms it uses for arguments. _______________________________________________________________________ Nick Maclaren No. In addition to the identified UTIs, inspection shows a comparable number of other technical issues that need resolving. There are also a number of wording problems, not all of which are simply editorial. _______________________________________________________________________ David Muxworthy No, for the following reasons. 1. Reasons for negative vote 1.1 The document is self-evidently not ready for issue as a PDTR, containing as it does six explicitly unresolved items. 1.2 Given the reservations expressed in N1844 and in subsequent email discussion it appears that significant technical problems remain to be resolved. I would withdraw this objection if paragraph 7 of the Foreword were changed to state that the facilities described in the document were experimental and not necessarily to be incorporated in a future standard[1], or if the project schedule were to be extended to allow further consideration of the proposals. This would also allow for addressing the concerns that implementation costs may be high relative to user benefits and that Fortran is losing some of the (relative) coherence and consistency gained in designing F90/95. See also 5.1 below. [1] The definition of a Technical Specification allows for this. 2. Comments on unresolved technical issues 2.1 UTIs 17 and 18: As a matter of principle any infringement that can be detected at compile time should be a constraint. 2.2 UTI 15: I agree with Malcolm's point. 3. Other comments 3.1 If it is decided in a future revision that Fortran should limit the range of values taken by variables, then '..' would be an obvious delimiter, as it is in Ada and Pascal. The symbol '..' should not be used here unnecessarily. 3.2 I would welcome an assurance that the new language features do not cause hidden interactions with, or unacceptable costs for, existing facilities, independent of interoperability. 4. Minor editorial points 4.1 The document refers to itself as both a TR and a TS. It should choose one. 4.2 References to J3 should of course be removed before submission. 4.3 Subclause A.1.6 uses KIND=4 and KIND=8 without any corresponding description. There should be a comment or the code should be generalized. 5. A contrary view 5.1 The original project specification, N1667, was to extend the functionality of passing Fortran arguments to C. It was not to change the Fortran language to accommodate a wider range of C arguments passed to Fortran or to incorporate further C concepts into Fortran. Clause 5 of this document would look out of place in a Fortran standard. The material would be more appropriate in a stand-alone document for those who need to use these facilities. While certain programming techniques may be common in C, it does not necessarily follow that Fortran should be distorted in order to accommodate them, unless there is very strong user demand. _________________________________________________________________________ John Reid 2) Yes, but I recommend the following changes. Comment: These changes include suggestions for resolving the UTIs for which Van Synder's vote has not already suggested changes. I would much prefer WG5 to submit a revised document that resolves all the UTIs and makes other changes that the Interop group accepts. ..................................................................... [3:14] Change "An" add "The name of an". [22:14] Change "An" add "The name of an". Reason: Names appear in designators, not variables. ..................................................................... [3:17+] Replace note 2.1 by "It is intend to allow an assumed-type object that is not assumed-shape and not assumed-rank to be passed as a simple pointer to the first address of the object. This would mean that there is insufficient information to construct an assumed-shape dope vector or C descriptor for an assumed-type explicit-shape array that is an actual argument corresponding to an assumed-shape dummy argument. Therefore TYPE(*) explicit-shape is not permitted." Reason: I don't see any definitive text that says that an assumed-type object that is not assumed-shape and not assumed-rank is passed as a simple pointer to the first address of the object and I don't think we should require it. We should allow a debugging compiler to pass the type. In any case, it is not our usual policy to tell vendors how to write compilers. ........................................................................ [5:15-16] Replace para 2 of 3.3 to "An assumed-type dummy argument may correspond to an actual argument that is of assumed type or any type except a derived type that has type parameters, type-bound procedures, or final procedures. If the actual argument is of assumed type and the dummy argument is not of assumed type, the actual argument shall be an object of assumed shape or assumed rank or a subobject of such an object and the type shall be one of those explicitly listed in Table 5.2." Reason: [3:10-11] says that an assumed-type entity has no declared type and its dynamic type and type parameters are assumed from its effective argument. If a Fortran object to passed to C and back as of assumed-type, the C descriptor will provide only the type information of Table 5.2, so the assumed type will be known only for the types explicitly listed in Table 5.2. A restriction is therefore needed for the case where an assumed-type object is associated with a dummy argument that is not of assumed type. ..................................................................... [11:11] Change "an intrinsic" to "a". [11:12] Change "companion" to "Fortran". Reason: Correct minor errors. ..................................................................... [13:8+] Add new third paragraph to 5.2.5.1 General: "A C descriptor for a Fortran pointer can be constructed by execution of the functions described in this section. If a Fortran object without the TARGET attribute is associated with a formal parameter in a call to a C function and a C descriptor for a Fortran pointer to the formal parameter or a part of it exists on return, the base_addr member of the C descriptor becomes undefined on return." [14:33-35] Delete the sentence "If the argument ...". [17:9-10] Delete the sentence "If source is not NULL ..." and DTI TR15. Reason: See DTI TR15. For Fortran calls to Fortran, an object without the TARGET attribute may be associated with a dummy argument that has the TARGET attribute. This is fine until return from the procedure, when any pointers associated with the dummy argument become undefined. We need the same rule for Fortran calls to C. CFI_establish_cdesc and CFI_setpointer have the wrong restriction and the rule needs to be more general. .................................................................... [13:23] At the end of the argument list add ", size_t elem_len". [14:7]. Before "The C descriptor" add "The argument elem_len is ignored unless type is a character type. Its value provides the length of an element of an object of character type." Reason: we should provide the functionality of the allocate statement for character objects. ....................................................................... [15:19-21],[16:6-8],[17:20-22],[38:32-34],[39:32-34] Change "->" to "." Reason: dims[0] is not a pointer. ....................................................................... [15:42] At the end of the paragraph, add "The values of the elements shall be such that they specify an array that could have been obtained by associating source with a Fortran assumed-shape array and applying array section notation in Fortran." Reason: In UTI TR16, Malcolm comments: "CFI section seems to allow nonsensical rank changing." I don't believe this is the case since we require the result C descriptor to describe a section of the array described by the source C descriptor. The edit aims to make this clear. ....................................................................... [17:1]. Change "CFI_dim_t dim[]" to "CFI_index_t lower_bounds[]". [17:4]. Change "dim" to "lower_bounds". [17:12-14] Replace the two sentences "Otherwise, ... ptr_dv" by "Otherwise, the number of elements in the array lower_bounds shall be greater than or equal to the rank specified in the source C descriptor. The elements provide the lower bounds for each corresponding dimension of the ptr_dv C descriptor. The extents and memory strides are copied from the source C descriptor." [17:17-23] Replace these lines by "to this with lower bound 0. CFI_index_t lower_bounds[1]; int ind; lower_bounds[1] = 0; ind = CFI_setpointer ( &ptr, &ptr, lower_bounds );" Reason: We should be providing the functionality of pointer association with the option of specifying the lower bounds and nothing more. ....................................................................... [17:7] Change " becomes a disassociated pointer" to "the C descriptor is updated to describe a disassociated pointer". Reason: Correct a minor error. ....................................................................... [17:23+] Delete UTI TR16. Reason: See the edits for [15:42], [17:1], [17:12-14]. The UTI also says "It would be helpful to create a list of all of the possible forms of pointer association and argument association involving dope vectors, and illustrate how each is accomplished with corresponding calls to these functions. It is possible the exercise would lead to a slightly changed set of functions." All that I see as missing is 1. The equivalent of pointer assignment with remapping. I don't think we should complicate CFI_setpointer with remapping - the C programmer can do this with CFI_establish_cdesc. 2. Array sections with vector subscripts. It has never been envisaged that vendors would construct descriptors for such array sections and that copies would be made when they are used as actual arguments - the C programmer can make copies explicitly. ....................................................................... [23:10] Change "an array or scalar" to "a data" and delete UTI TR19. Reason: The UTI can be resolved by changing the sentence to which it refers to be that in 2.2. ....................................................................... [31:33 to 33:14] Delete A.1.3 and UTI TR20. Reason: This example is not valid in view of the constraint in 2.1. ______________________________________________________________________ Jim Xia No, for the following reasons 1.) allow the same C descriptor to be used in CFI_setpointer(). This is a bad idea to begin with, and will cause grief in compiler optimizers. 2.) there are apparent overlapping functionality between CFI_setpointer() and CFI_section(). It's confusing to understand exactly which does what, or when to use which. It's also not clear to me which one will result in zero-based array section or one-based array section. 3.) allow Fortran ALLOCATABLE variables to be allocated on one side (C or Fortran) and then deallocated from the other side. This likely will cause many implementation difficulties. Addition comments from IBM (C side people) 3.3.{3,4} Seems to indicate runtime or generated code should do deallocation. Note that in C if no stdlib is included and no C lib is linked, this force programs to link in a library that they didn't want. 5.2.2: base_addr: Says if the object has zero size the value is not NULL. However the C standard allows NULL return values from malloc(0). 5.2.2, 5.2.3: Was there a reason to allow any order for the middle elements? This seems to decrease portability between compilers. 5.2.4 p3 seems to conflict with 5.2.5.5 p7, should the 15 there not be the macro value? 5.2.5.5 p3 indicates that it can establish a C descriptor for an object or a subobject of it implying that even if the user wanted a descriptor for an object they could end up getting a descriptor for a subobject. 6.3 p3 Grammar error: "that are *of* assumed type". I think the first comment is serious enough to reconsider the requirement on INTENT(OUT) for allocatables. ______________________________________________________________________ Reinhold Bader Vote on the informal ballot on N1845: "Is N1845 ready for forwarding to SC22 as the PDTR?" 3) No, for the following reasons: * There are still too many outstanding minor change requests * The CFI_* interface is not yet fully stabilized (witness the varying length string allocation issue, and possible CFI_setpointer problems) This being said, I think that the next iteration of the TR draft, to be produced at or shortly after the June 2011 meeting has a good chance to be solid enough for a submission as a PDTR (unless some new and really major problem is uncovered between now and the end of the meeting). (A) Comments and suggestions for changes: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [v, para 4]: The sentence "New Fortran concepts ... declared (void *)." needs rewording; assumed-rank is independent of void * arguments. TR17: I agree that this restriction should be a constraint. [9:34-35]: After recent discussions about dead weight in the descriptor - does this not also apply to the version component of CFI_cdesc_t? (Given the first sentence of NOTE 5.3 I don't think adding this feature is worth the trouble. Witness the need to completely recompile Fortran code whenever the module information format is incompatibly changed). [12:NOTE 5.4]: Should there not be the requirement in normative text that the macro values for C types interoperating with the same Fortran type must be the same? [13:6-8]: Fortran pointers can also be associated via CFI_setpointer(); the paragraph also needs rewording so it is clear that "Within C" applies to all of it. [Section5.2]: As noted by Van, the function prototypes lack explicit formal parameter names; these should be added. Furthermore the examples given in subsections 5.2.5.5, 5.2.5.8 and 5.2.5.9 should be moved to Annex A. [14:22-24]: For a C formal parameter of type (CFI_cdesc_t *), a corresponding Fortran dummy argument need not exist, but the requirement should be fulfilled anyway. Furthermore, the requirement itself is replicated three times for as many intrinsics, so it is suggested to move this to section 5.2.6 (see also [17:26] below) [14:34-35]: This may also be impacted by UTI TR15. [15:30+]: It appears to me that CFI_section does not provide any functionality which is not covered by CFI_establish_cdesc. The only example in the TR is [16:3-9], and that can also be changed to use CFI_establish_cdesc instead. Why not remove this function? (the same argument could be applied to CFI_select_part, however the latter function does make subobject selection code easier to read, so I'd be OK with retaining it). [17:1]: John Reid has suggested replacing the CFI_dim_t parameter by a lower bounds argument. However, this change makes the example in para 7 unworkable. Why not have a full subscript triplet array CFI_dim_t subscripts[3][] as a replacement for dim[]? [17:26-18:1]: N1830 has two constraints (C539/C540) here which may require some modification since within a C implementation checking violations at compile time will probably not be possible (there may also be an issue in F2008 for the case where an interface is specified separately from the implementation). Furthermore, the TR should also differentiate between modifying data (for non-pointers with INTENT(IN)) and metadata (for pointers). [18:5-7]: This appears at least partly superfluous, at least it is not very clearly worded. There's a suggestion for changes to [9:3-5] below which would allow to remove this. [31:16]: "would be rejected during compilation" requires that 2.1 para 3 is made a constraint. UTI TR20: Apart of the removal or modification of A.1.3 it will also be necessary to make changes to [29:12-13]. [A.1.3]: It is suggested to replace this example by a valid one which illustrates the array subobject handling capabilities and type resolution for an unlimited polymorphic actual argument. I'll write this up as a separate paper, which will be submitted for the June meeting. [36.10-37:31]: The bracketing convention used here is different from C code elsewhere. [36:11+]: The include files and are missing here; at least a comment about omitted includes should be added. [A.2.2]: There still are some typos in the example C code. [A.2.3]: There still are some bugs in the C code (apart of the "->" ones previously pointed out). Some of the explanatory text also requires improvement. [38:49+]: The wording still reflects the assumptions in N1838 and requires some changes. [40:10-24]: operating with CFI_establish_cdesc on ip violates the requirements of 5.2.5.5 para 2. Therefore, a separate descriptor must be constructed for pointing to the C entity "y", and associated with the original descriptor via CFI_setpointer. I am considering doing further changes to this example to integrate [17:16-23], and the CFI_setpointer function may change, so there are presently no edits for this. (B) Suggested edits for most of the comments from (A): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [v. para 4]: Replace "New Fortran concepts ... declared (void *)." by "New Fortran concepts of assumed-type and assumed-rank are introduced. The former facilitates interoperation with formal parameters of type (void *); both features together remove the necessity to write large numbers of specific calls in a generic Fortran interface to support arbitrary array ranks and types in a library call which implements generic functionality. [9:3-5]: Replace "with standard prototypes provide" by "specified in 5.2.5 provides". Replace "for describing an" by "for creating, referencing and defining a Fortran". (this indicates more clearly that not only dummy arguments are handled, but also Fortran object management within C is supported). After "data pointer object" add "of interoperable type" (for non-interoperable types it is allowed to pass a handle through C - do we want to mention this explicitly?) [9:34-35]: Delete the version component from CFI_cdesc_t. [11]: From NOTE 5.3, replace ", and that the version ... Technical Report." by ". Such a change indicates that all C source code using the facilities provided by ISO_Fortran_binding.h must be recompiled." [11:13+]: Add "The specifiers for two intrinsic C types must have the same value if they interoperate with the same Fortran type." (It might even be desirable to fix these to be the same value as the corresponding Fortran KIND number so you can pass them through to Fortran) [12:1-]: Remove NOTE 5.4 [13:6-8]: After "Within a C function, " start a bullet list with "* allocatable objects ... functions. * a Fortran pointer ... function", and add ", or by execution of the CFI_setpointer function" to this second bullet. [14:19]: After "an assumed-shape array, ", add "an array section, ". [14:22-24]: Delete "It shall not point ... Fortran dummy argument". [14:27]: after "1999 3.2)", add " and of sufficient size". After " type", add ", rank and dimensions". [14:41-42]: Replace "specifying the dim information" by "which will be written to the dim[] member of dv" [14:43+]: Add "NOTE 5.5+: If the base_addr is that of a Fortran array accessed via a C descriptor /d/, dim[] can be constructed from /d->dim[]/ such that dv describes an array subobject of /d/. It is the responsibility of the programmer to ensure that the settings of dim[] as well as the other arguments provide a consistent view of the layout of the original Fortran object." (with respect to UTI TR 16 note that CFI_establish_cdesc effectively also allows nonsensical rank changing. But we can't really change this since we also want to be able to plug in addresses of C objects here). [15:30-16:10]: Delete CFI_section. (If this is retained, [15:35-36] may require modification in analogy to [14:22-24].) [16:17-19]: Same as [14:22-24] above. [17:26+]: Replace "A C descriptor that is ... not be updated" by "The following rules apply for a C descriptor /d/ that describes an object that is described by a C descriptor pointed to by a formal parameter /dvarg/ of type (CFI_cdesc_t *): * /d/ must not appear as the dv argument in a call to CFI_establish_cdesc[, the result argument in a call to CFI_section], or the result argument in a call to CFI_select_part. * if a Fortran dummy argument corresponding to /dvarg/ exists and has the INTENT(IN) attribute, /d/ must not appear as the XXX argument in a call to CFI_allocate or CFI_deallocate. * if a Fortran dummy argument corresponding to /dvarg/ exists and has the INTENT(IN) and POINTER attributes, /d/ must not appear as the ptr_dv argument in a call to CFI_setpointer. * if a Fortran dummy argument corresponding to /dvarg/ exists and is a non-pointer entity with the INTENT(IN) attribute, no modification of data accessible via /d->base_addr/ is permitted." Add "NOTE 5.5+: For Fortran pointer entities with the INTENT(IN) attribute it is recommended that the C programmer add a 'const' specifier to the corresponding parameter of type 'CFI_cdesc_t *' in the C prototype." [18:5-7]: Delete these lines. [29:6]: Replace "entities whose dynamic type is interoperable with C" by "dummy arguments in a BIND(C) interface" [29:8]: Replace "This is a start address" by "This could be a start address". [29:10]: Delete "or explicit shape". [29:12-13]: Replace "All unlimited polymorphic ... shape or rank," by "All assumed-type entities of assumed shape or rank". [31:31]: Prepend "status =" with "*". [37:34]: Replace "desirable" by "necessary". [37:39-41]: Replace "CFI_DESC_T" by "CFI_CDESC_T" and (3 times) "CFI_cdest_t" by "CFI_cdesc_t". [37:43]: Rewrite line as "CFI_rank_t rank = 2; int flag;" [37:51] and [38:10]: Remove "[]" in "dims[]" [38:32-34] Replace "->" by "." (3 occurrences) [38:36]: Before "&array", insert "(CFI_cdesc_t *)" [38:44]: Before "array", insert "(CFI_cdesc_t *) &" [38:49-39:4]: Replace the text by "A copy of the incoming descriptor must be created because of the provisions in section 5.2.6." <> "The example demonstrates why these rules are reasonable: If the original descriptor were updated with the dim[] settings above, it would be irreversibly modified, preventing access to some of its original data in the implementation's code after invocation of CFI_establish_cdesc or - after the call site - for a C function which invokes set_odd (see below). [39:27+]: Add a line "CFI_index_t subscripts[1];" [39:32-34]: Replace "->" by "." (3 occurrences) [39:36]: Before "&d", insert "(CFI_cdesc_t *)" [39:41]: Remove last blank in "rank * /" [39:44]: Before "d", insert "(CFI_cdesc_t *) &" [40:2]: Before "d, subscripts", insert "(CFI_cdesc_t *) &" (C) Edits for minor wording changes and typos: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [9:17]: Replace "no effect different from" by "an effect no different from" [13:13]: Replace "which error condition ... dependent" by "it is processor dependent which error condition is detected" ______________________________________________________________________ Richard Graham Dear member of the WG5 and J3 Fortran standardization committee, First, we want to thank you for your effort in defining the TR 29113 as an important key to solve the problems between MPI and Fortran. This is a comment from the MPI Forum on your WG5 letter ballot on N1845 in ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1846.txt and http://www.nag.co.uk/sc22wg5/. After reading your N1845 working draft from March 3, 2011, we detected one major gap: there is no standardized possibility of using nonblocking features of MPI in Fortran programs to overlap computation with communication. Specifically, Fortran MPI applications will be prohibited from initiating any form of asynchronous communication and then continuing to perform local computations while MPI advances the communication "in the background." This is a key issue for us because nonblocking communication is a critical technique for deadlock-free communication and high performance performance. An easy use case to describe is one that is popular in current high performance computing environments: when the MPI library utilizes hardware offload technologies (such as RDMA) with a communication co-processor (such as a NIC). The problem is, in principle, independent of MPI. It also occurs with libc/POSIX asynchronous IO (aio), and is therefore a topic that should be solved by the "TR on further interoperability of Fortran with C." We noticed that there is already a decision about this issue: to extend the meaning of the ASYNCHRONOUS attribute rather than to define a new attribute. http://www.j3-fortran.org/doc/year/09/09-235r2.txt contains the minutes from the J3 meeting, May 4-8, 2009. On this topic, the following vote was recorded: Paper 09-231 "Answer to MPI Forum regarding MPI asynchronous operations" [Rasmussen] discussed how to prevent code-motion and copy-in/out: SV: extend ASYNCHRONOUS - invent new attribute - undefined: 8-2-3 First, we would like to propose how to solve the problem, then we will present a short example to illustrate the specific problem. We recommend the following change of the first two paragraphs in this section of the Fortran 2008 standard: 5.3.4 ASYNCHRONOUS attribute 1 An entity with the ASYNCHRONOUS attribute is a variable that may be subject to asynchronous input/output or other asynchronous access by means other than Fortran. Asynchronous input/output can be any asynchronous access to the variable or parts of it, potentially within the scope of this standard by Fortran asynchronous I/O or possibly via methods outside the scope of this standard, such as the libc/POSIX asynchronous IO (aio) or nonblocking message passing, one-sided communication, or nonblocking parallel I/O as part of the Message Passing Interface (MPI) standard. 2 The base object of a variable shall have the ASYNCHRONOUS attribute in a scoping unit if - the variable appears in an executable statement or specification expression in that scoping unit and - any statement of the scoping unit is executed while the variable is a pending I/O storage sequence affector (9.6.2.5) or any other pending asynchronous access by means other than Fortran. This should be treated only as a wording proposal. We provide the above text only as a suggestion; J3/WG5 are certainly free to adjust it as they feel necessary. The key idea is that we need ASYNCHRONOUS to also include potential memory modifications from agents outside the scope of the Fortran standard. The following snipit is a correct code that allows the MPI library to internally use DMA, communications offload (e.g., to a NIC), or other method to asynchronously communicate parts of the array while the user application/main CPU simultaneously reads and writes to ***another*** part of the same array. Specifically, this code snipit is is free of race conditions. USE mpi_f08 REAL, ASYNCHRONOUS :: buf(100,100) ! communicating a boundary of the array: CALL MPI_Irecv(buf(1,1:100),...req,...) DO j=1,100 DO i=2,100 buf(i,j)=.... ! work only on the inner area END DO END DO CALL MPI_Wait(req,...) It is important that the compiler is ***not*** allowed to translate this program (by using temporary memory modifications) into something like this: USE mpi_f08 REAL, ASYNCHRONOUS :: buf(100,100), buf_1dim(10000) EQUIVALENCE (buf(1,1), buf_1dim(1)) CALL MPI_Irecv(buf(1,1:100),...req,...) tmp(1:100)=buf(1,1:100) ! saving the boundary DO k=1,10000 buf_1dim(k)=... ! work on the whole array END DO buf(1,1:100)=tmp(1:100) ! restoring the boundary CALL MPI_Wait(req,...) While the MPI library receives buf(1,1:100) "in the background", the "work" part overwrites this part of the array as part of a numerical optimization to achieve one long loop instead of a 2-loop-nesting. With the current status of Fortran 2008 + TR 29113 (Version N1845), a compiler can ignore the ASYNCHRONOUS attribute. For example, a compiler may choose to not implement Fortran asynchronous I/O in an asynchronous way, meaning that there is no need for the compiler to make any restrictions on optimization. To be clear: with the current Fortran 2008, this optimization is still allowed. With our proposal, this optimization will be prohibited. We want to mention that the use of VOLATILE would solve the problem, but at a high performance price because it would also prohibit any optimization of the "work" part (e.g., automatic cache optimization, instruction reordering, etc.). Especially since Fortran is used with MPI in high-performance, numerically intensive applications, we feel that VOLATILE cannot be recommended as a solution. In the era of multi-core hardware and vector instructions on each CPU, nonblocking communication must be allowed to overlap with efficient numerical code written in Fortran in order to achieve scalable, highly-performance applications. Your vote in J3 gave us the confidence that you can solve this problem within your TR 29113. In short, if we were members of WG5, we would answer the ballot with "Yes, but I recommend the following changes..." with the proposal described above. We appreciate the fact that you have asked for external comments on N1845. We hope that our comments above are sufficient information, and also hope that this letter conveys the critical importance with which we consider this issue. Many thanks for your time. _____________________________________________________________________ Craig Rasmussen _______No, for the following reasons: The requirements in paper 09-231 "Answer to MPI Forum regarding MPI asynchronous operations" from J3 meeting 188 seems to have fallen between the cracks. In a straw poll, J3 voted (8-2-3) to extend ASYNCHRONOUS to restrict optimizations on variables that may be accessed asynchronously. The minutes state that no further action will be taken on 09-231 and other papers as they are all input for the Interop TR N1761. In section 5.2.7 of N1845, Restrictions on lifetimes, it states that all C pointers to any part of an object described by a C descriptor become undefined on return from the function unless the dummy argument has the TARGET, ASYNCHRONOUS or VOLATILE attributes. However this only applies to attributes on the dummy argument and N1845 makes no mention of extending the ASYNCHRONOUS attribute. In particular, this is important with regards to a variable that may be accessed asynchronously, but may not be argument associated with a dummy with the ASYNCHRONOUS attribute, as the compiler has no knowledge of the asynchronous access. It seems to me that in order to satisfy the requirements in 09-231 that text in section 5.3.4 must be modified somewhat. There are also other issues that are more minor and can be easily fixed: 1. Page 1, line 7: Replace "excution" with "execution". 2. Page 9, 5.2.2: CFI_cdest_t contains a flexible array member and there is a macro CFI_CDESC_T for declaring a C descriptor with a given rank, however there doesn't appear to be a function to obtain the sizeof a CFI_cdest_t with a given rank. A mechanism to obtain the size of a C descriptor is necessary if one needs to create a long-lived descriptor in C using malloc. 3. Page 14, following paragraph 7: There is no description of the dim argument. 4. Page 15, lines 19-21: 5.2.3 states that CFI_dim_t is a named struct type defined by a typedef. Thus CFI_dim_t is not a pointer type yet pointer dereferencing is used in lines 19-21, e.g., dim[0]->lower_bound should be dim[0].lower_bound. 5. Page 16, lines 6-7: See comment in item #4 above. 6. Page 16, lines 8-9: The type of the source variable is not stated, in particular, whether it is a pointer. The usage in line 8 implies it is a pointer, the usage in line 9 that it is not a pointer. 7. Page 16, line 40: Replace "component,;" with "component;" 8. Page 16, line 44: The use of sizeof(d) for the displacement argument assumes a particular layout of the interoperable type t, which is processor dependent. 9. Page 17, lines 20-23: See comment in item #4 regarding pointer dereferencing of dim[0]. 10. Page 18, line 23: It is stated that ptr point to a C descriptor yet the address operator & is used with ptr in the call to CFI_setpointer. ______________________________________________________________________ Bill Long 2) Yes, with changes. I've been accumulating the various (and many) edits proposed to the TR as part of this informal Ballot. They seem to fall into these categories: 1) Typos (spelling, punctuation, etc.) 2) Non-controversial corrections to wrong statements or C program example syntax. 3) Wording changes that improve clarity, but do not make technical changes. 4) Reformatting the presentation of the function descriptions in 5.2.5. 5) Minor technical changes that address oversights in the current draft. 6) Technical changes on which there is not consensus. 7) Proposals for edits that are based on some misunderstanding and are unlikely to be accepted. My preference would be to create an updated draft based on the edits for categories 1-5, have a subgroup review the result as a PDTR candidate, and leave the comparatively small number of issues in category 6 for responses to the PDTR ballot and resolution at the June meeting. ______________________________________________________________________ Robert Corbett I abstain due to lack of time to prepare a proper response. _____________________________________________________________________