J3/06-014r1 To: J3 From: Malcolm Cohen Subject: Cumulative edits for F2008 development Date: 2006/06/30 1. Introduction =============== This contains the combined edits from all passed papers at meetings 173, 174 and 175, plus the "enhanced module" TR 19767 and the editor's report thereof 05-169 (the latter changes some edits and deletes others). Some typos in the papers have been corrected in this list. Some comments appear. All edits appear in page and line number order. There will not be a combined document with them separated out into "feature" order; refer to the original papers for that information. 2. List of papers ================= >From meeting 169: TR 19767 (04-324). >From meeting 171: 05-169 (Editor's report on TR 19767). These are not separated out from TR 19767. >From meeting 173: 05-194r1, 05-196, 05-198r1, 05-199r2, 05-200r1, 05-201r2, 05-202r1, 05-204r2, 05-205r2, 05-210r2, 05-231r4, 05-232r1, 05-233r2, 05-234r2, 05-237r4, 05-240r4. >From meeting 174: 05-260r1, 05-264r3, 05-268r3, 05-273r3, 05-275r3, 05-278r2, 05-279. >From meeting 175: 06-108r1, 06-113, 06-114r2, 06-115r1, 06-137, 06-138r2, 06-139r1, 06-140r1, 06-141, 06-142, 06-143, 06-146, 06-149. Rejected papers from meeting 175: 06-128r1. The edits from this paper have been omitted. >From meeting 176: 06-154r4 (not including the editorial suggestions), 06-158r2, 06-167r1, 06-168r2, 06-172r2, 06-174r3, 06-175r2, 06-176, 06-181r1. NOTE FROM THE EDITOR: 06-175r2 has a number of serious technical issues. Resolving these will almost certainly delay the standard. We should consider omitting the feature instead. Note: 06-181r1 had the rather ambitious editing instruction "Add BACK= to MAXLOC and MINLOC, similar to FINDLOC above, after the edits have been accepted.". Since the edits already added BACK= to the summary table for MAXLOC and MINLOC, this has been done. Thanks to Dick Hendrickson for his help on this. 3. Some LaTeX-isms ================== LaTeX Normal convention Notes ----- ----------------- ----- \si{xyz} Syntax item xyz. (\ref{Dn:title}) (some number) Cross reference to subclause "title", located in clause "n". \obs{text} {text} Obsolescent font. 4. List of edits ================ 05-234r2: [xiii] Introduction, the list of new Fortran 2008 features should include "The maximum rank of an array has been increased from seven to fifteen." 05-237r4: [xiii] Introduction, the list of new Fortran 2008 features should include "Performance enhancements: The DO CONCURRENT construct, which allows loop iterations to be executed in any order or potentially concurrently." 05-279: [xiii] Add something about non-null initial targets for data and procedure pointers to the introduction. 05-273r3: [xiii] Add an item "Performance enhancements: CONTIGUOUS attribute." 06-114r2: [xiii] Add an item "The ATAN intrinsic is extended so that ATAN (Y, X) is ATAN2 (Y,X)." 06-115r1: [xiii] Add an item "Allocatable components of recursive type." 06-137: [xiii] Say something about MOLD=? NOTE FROM THE EDITOR: The paper didn't say to add anything here, but... 06-138r2: [xiii] Add an item "OPEN statement enhancements that allow the processor to select a unit number when opening an external unit. Such a unit number is guaranteed not to interfere with any program-managed unit numbers." 06-142: [xiii] Add new feature "The BLOCK construct (allows declarations within executable statements)." 06-149: (superceded by 06-176?) [xiii] Add new feature "A disassociated pointer actual argument or a deallocated allocatable actual argument can be associated with a nonpointer nonallocatable optional dummy argument, in which case the dummy argument is assumed not to be present.". NOTE FROM THE EDITOR: Too long and complicated, alternative is: "Additional functionality for allocatable and pointer actual arguments." {This also covers pointer function reference actual arguments.} 06-176: [xiii] Alternative to 06-149 above: "A disassociated or deallocated actual argument can correspond to an optional nonpointer nonallocatable dummy argument." 06-154r4: [xiii] Invent some blather about \si{variable} having more meanings. 06-167r1: [xiii] insert something like "The COMPILER_VERSION and COMPILER_OPTIONS functions provide information about the translation phase of the execution of a program." 06-168r2: [xiii] insert something like "a statement-level macro processing facility". NOTE FROM THE EDITOR: 06-168r2 forgot to insert anything like this. 06-181r1: [xiii] insert something about FINDLOC, e.g. "A FINDLOC intrinsic was added and a BACK= argument was also added to MAXLOC and MINLOC." or alternatively, more vaguely "Exhanced intrinsic procedures for searching arrays." NOTE FROM THE EDITOR: The paper forgot to insert anything here. 06-174r3: [xiii] Add new feature "Parallel programming support: SPMD parallel programming, co-arrays for data exchange between images, image control statements, and collective procedures.". 06-175r2: [xiii] Add new feature "A BITS data type for non-numeric programming and enhanced handling of BOZ constants.". 06-175r2,06-174r3: [3:5-9] Retain. NOTE FROM THE EDITOR: Introduce new "1.6.1 New intrinsic procedures". 06-175r2: [3:10-] Insert new subclause "1.6.2 Fortran 2003 compatibility This standard specifies a new intrinsic type, BITS, which will conflict with a user defined type of the same name. This standard specifies a new intrinsic operator, .XOR., which might conflict with a user-defined operator of the same name, and has a different precedence than in previous standards." NOTE FROM THE EDITOR: Modified. TR 19767: [9:12+] 2.1 High level syntax, BNF R202 , after "<> " insert "<> ". TR 19767: [9:34+] 2.1, after BNF R1104 , insert new BNF rule "R1115a <> [ ] [ ] " 06-168r2: [10:11+] 2.1, R207 , add new production in alphabetic order, "<> ". 05-196: [10:24] 2.1 High level syntax, BNF for R210 , Delete first "" . 05-196: [10:29] 2.1 High level syntax, BNF for R1107 , Delete first "". TR 19767: [10:32+] 2.1, BNF for , add another alternative: "<> ". 06-142: [10:53+] 2.1 High level syntax, R213 executable-construct, add new production in alphabetic order "<> ". 06-174r3: [10:53+] 2.1, R213, add new production in alphabetic order "<> ". 06-174r3: [11:24-31] 2.1, BNF R213 , add new productions in alphabetic order "<> <> <> <> <> <> ". 06-168r2: [11:38+] 2.1, append new paragraph to subclause: "Additionally, an EXPAND statement may occur anywhere that any statement may occur other than as the first statement of a program unit. The syntax rules are applied to the program after macro expansion, i.e. with each EXPAND statement replaced by the statements it produces." TR 19767: [11:41] 2.2 Program unit concepts, first paragraph, second sentence, after "module" insert ", a submodule". TR 19767: [11:43] 2.2, first paragraph, after the fourth sentence, (before "A block data ...") insert new sentence "A submodule is an extension of a module; it may contain the definitions of procedures declared in a module or another submodule." TR 19767: [11:45] 2.2, first paragraph, seventh sentence, between "module" and ", or another subprogram", insert ", a submodule". TR 19767: [11:47] 2.2, first paragraph, last sentence, between "module" and "but", insert "or submodule". TR 19767: [12:28] 2.2.3.2 Module procedure, second sentence, between "module" and "containing", insert "or submodule". TR 19767: [13:17+] After subclause 2.2.4 Module, insert new subclause: "2.2.5 Submodule A <> is a program unit that extends a module or another submodule. It may provide definitions (12.5) for procedures whose interfaces are declared (12.3.2.1) in an ancestor module or submodule. It may also contain declarations and definitions of other entities, which are accessible in descendant submodules. An entity declared in a submodule is not accessible by use association unless it is a module procedure whose interface is declared in the ancestor module. Submodules are further described in Section 11. Note 2.2a The scoping unit of a submodule accesses the scoping unit of its parent module or submodule by host association.". 06-174r3: [13:17++] Immediately before 2.3 Execution concepts, add new subclause, NOTE FROM THE EDITOR: This belongs as 2.3.5 (within Execution concepts) at [15:25+], not here. I cannot see how the stuff about image replication and execution is not part of "Execution concepts". I will probably move it there unless given some very good reason. COMMENT TO THE EDITOR: In 2.3 somewhere is fine, but the concept is referenced earlier in 2.3 so ... check wording/forwardref, or put it earlier than the reference. "2.2a Images A Fortran program executes as if it were replicated a number of times (which may be one), the number of replications remaining fixed during execution of the program. J3 TECHNICAL NOTE In post-draft discussions it has been variously and contradictorily contended that the concept of program does not include all the images. It is certainly contradictory in the edits. Look, if we *have* a definition of single-threaded Fortran (like we used to) then we can layer ***SOMETHING ELSE*** on top of it and replicate as we please without affecting the single-threaded concepts. But tightly integrating them does not give us this ability. If "program" is meant to include only the execution and data entities of a single image, we still need a name for the concept that is the "Co-Fortran program" providing the semantics for the whole "Co-Fortran" thing. \end{j3note} Each copy is called an <> and has its own set of data objects and procedure pointers. Each image executes asynchronously." Note 2.xx The programmer controls the progress of execution in each image through explicit use of Fortran control constructs (\ref{D2:Execution sequence}). The image control statements (8.5.1) affect the relative progress of execution between images. Co-arrays (2.4.5a) provide a mechanism for accessing data on one image from another image." NOTE FROM THE EDITOR: As suggested, I've turned the unimportant waffle sentences into a note (for the porpoises of providing "useful cross references"). Probably, \ref{D2:Execution sequence} should be \ref{D8:Executable constructs containing blocks} plus \ref{D8:Branching}? Comments? "J3 TECHNICAL NOTE Missing from the "own set" is execution state, however we say it. It has been contended that all of that is implicit in "executes asynchronously", but since there are many points of non-asychronous behaviour - e.g. in image termination effects - just how far that extends is emphatically NOT obvious. IEEE modes, external units, file system, we all need to know. Otherwise it is not standardised (a situation we should all hope to avoid). Either we should say that "All other entities are shared between the images" (after putting execution state into the "own" set!), or we should specify the entities that are shared; at least then any entity that does not fall into either list can be seen to be a problem... I suppose I recommend the latter course. Once this is fixed the edit at [178:36] can be turned into a note instead. (Actually, I think the whole paragraph at 178:35-36 should probably be inside the note, since we already say this under "scoping".) Each image is identified by an <>, which is an integer value in the range one to the number of images. A processor shall contain the capability of executing a program on a single image." NOTE FROM THE EDITOR: Replaced note 2.2a (which was trivial and problematic) with a normative requirement that a processor can execute traditional Fortran programs. Otherwise, it would be conforming for a processor to always run a program in (e.g.) 8 images, which would produce nonsense results for normal programs. "NOTE 2.2b A processor might allow the number of images to be chosen at compile time, link time, or run time. It might be the same as the number of CPUs but this is not required. Compiling for a single image might permit the optimizer to eliminate overhead associated with parallel execution. Portable programs should not make assumptions about the exact number of images. The maximum number of images may be limited due to architectural constraints. [end NOTE] A <> is a set of images formed by invoking the intrinsic collective subroutine FORM_TEAM (13.7.25l) for the purposes of collaboration. A team is identified by a scalar variable of type IMAGE_TEAM (13.8.2)." NOTE TO THE EDITOR 13.7.25l actually means 13.7.39a... TR 19767: [14] 2.3.2 Statement order, Table 2.1, first row (second line), after "MODULE" insert ", SUBMODULE". TR 19767: [14] 2.3.2, Table 2.2, third column, heading, change "Module" to "Module or Submodule". TR 19767: [14] 2.3.2, Table 2.2, second footnote, - change "a module" to "a module or submodule" - change "the module" to "it". TR 19767: [14:2,4,6] 2.3.3 The END statement, - first sentence, after " insert "", and after "" insert ""; - third sentence, replace "and " by ", and ". - first sentence, replace "or " by ", , or ". TR 19767: [15:2] 2.3.3, last paragraph, after "", insert ", ,". 06-174r3: [15:19+] 2.3.4 Execution sequence, after the second paragraph, insert new paragraph "The relative ordering of the exeuction sequences of different images can be affected by image control statements (8.5)." NOTE FROM THE EDITOR: I accepted some suggested alternative wording for this edit, which was previously problematic. 06-174r3: [15:20] 2.3.4, last paragraph, first sentence "Normal termination ...", Replace with "Normal termination of execution of the program occurs on all images if a STOP statement or is executed immediately after a SYNC_ALL (8.5.2) statement on all images. The stop code, if any, and warnings of any exceptions that are signaling (8.4) shall be made available only for image 1. J3 TECHNICAL NOTE (1) Since there is only one program, I do not see how "Normal termination of execution" can be qualified by "occurs on all images". If execution of the program is terminated, since that execution is all of the image executions, each image is terminated. This is straightforward from the first sentence of 2.2a." NOTE FROM THE EDITOR: It was suggested to me that the issue was whether termination was "normal" on all images; well, if it is normal for the whole program, it is normal on all images. I will have a go at rewording this later (when producing the 007?) to try to capture what I think is meant here without being confusing/misleading. "J3 TECHNICAL NOTE (2) "shall be made available only for image 1" is problematic since after normal termination no images exist. I do not understand what is meant here. Maybe (?) it is that any signalling exception on any image other than 1 is not reported?" NOTE: "This is in direct response to complaints about MPI programs printing ``Fortran STOP'' to the screen 10000 times." THE EDITOR SAYS: There does not appear to be anything in the standard which prevents a processor from printing ``Fortran STOP'' to the screen 10000 times even in single-process Fortran 77. I think that is purely and simply a matter of QoI (or possibly even outwith the scope). If we want to say something here it should almost certainly be *a note* along the lines that since a program is a program, however many "images" it contains, that processors should be circumspect about reporting identical statuses multiple times on image termination. "Anyway, failure to report signalling exceptions just because they are on images other than one is poor design. The consequences of overflow and invalid operations are just as potentially serious whether the computation takes part on image 1 or some other image. It would be preferable not to disallow a conscientious processor from reporting such problems. Finally, this is a small detail. There is currently no mention of what happens with signalling exceptions in clause 2, and so no need to mention how it differs with co-arrays. Therefore the second sentence should be deleted. [end J3 note]". 06-174r3: [15:25+] 2.3.4, end of subclause, add new paragraph and note, "When a STOP or that does not immediately follow a SYNC_ALL statement is executed on an image, normal termination occurs on that image. The stop code, if any, and warnings of any exceptions that are signaling (8.4) shall be made available only for that image. The executions of all other images are terminated. J3 TECHNICAL NOTE This is inconsistent with the behaviour after SYNC_ALL (unless image 1 always restarts first after a SYNC_ALL). This is going to cause headaches for the implementors (STOP has multiple meanings, and does different things according to context - ugh). There seems to be two competing theories for what STOP is for here: (1) a programmer-initiated error termination (2) a normal termination and the decision as to which STOP is which kind is being determined by whether it is preceded by SYNC_ALL (not that this is adequately defined, see J3 notes in the STOP statement section). In previous Fortrans, STOP is normal termination. That's it. It is not "CALL ABORT". If we want a second kind of STOP, perhaps we should consider adding a second kind of STOP, perhaps spelled QUICKSTOP or something. AND OF COURSE THE WORDING IS BAD, BUT THAT CAN BE FIXED BY DELETION. NOTE 2.2c When a STOP or statement is executed on an image, how soon termination takes place on another image is processor dependent. [end NOTE] J3 TECHNICAL NOTE Presumably this is referring to the "error STOP" (or the "STOP not after a SYNC_ALL") situation, since it does not appear to be processor-dependent in the "normal STOP" case. Or perhaps it is... again, this doesn't seem to be well-defined.". 06-175r2: [15:39] 2.4.1.1 Intrinsic type, first pargraph, second sentence, Change ", and logical" to ", logical, and bits". 06-175r2: [16:2-3] 2.4.1.1, second paragraph, first sentence, Delete "and" before "representation methods", Append to sentence ", and the number of bits for the bits type (4.4.6)". NOTE FROM THE EDITOR: Instead of the above, I will replace the sentence with "The <> indicates the representation method for the specified type." because this is better than the existing text, and still true for bits. 05-260r1: [17:1] Delete the last sentence of 2.4.3.1 "Subobjects of complex ...". TR 19767: [17:4] 2.4.3.1.1, second paragraph, first sentence, after "module" insert ", submodule". 06-142: [17:6] 2.4.3.1.1 Variable, second paragraph, after "or host association." Insert new sentence "A named local variable of a BLOCK construct is a named variable that is declared in that construct, is not in COMMON, does not have the BIND attribute, and is not accessed by use association." 05-234r2: [18:5] 2.4.5 Array, second paragraph, first sentence, change "seven" to "fifteen". 06-143: [18:16-17] 2.4.5, third paragraph, penultimate sentence, Delete ", and all such element operations may be performed in any order or simultaneously". [18:17+] 2.4.5, immediately after the third paragraph, insert new note "NOTE 2.4a If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.7), the element operations may be performed simultaneously or in any order.". 06-174r3: [18:20+] Immediately before 2.4.6 Pointer, add new subclause "2.4.5a Co-array A <> is a data entity that is declared with nonzero co-rank and may be referenced or defined by any image. It may be a scalar or an array. For each co-array on an image, there is a corresponding co-array with the same type, type parameters, and bounds on every other image. The co-array on any image may be accessed by using s. On its own image, a co-array may be accessed without use of co-subscripts. The <> of a co-array is the number of co-dimensions. The <> of a co-array is always equal to the number of images. J3 TECHNICAL NOTE The term "co-dimension" is not defined. It would probably be better to define co-array in terms of being a rectangular set of objects in co-rank "co-dimensions" etc., similarly to how we define arrays. An object whose designator includes an is a <>. For each co-array, co-subscripts are mapped to image indices in the same way as Fortran array subscripts are mapped to the position of the array element in array element order (6.2.2.2). Intrinsic procedures are provided for mapping between an image index and a list of co-subscripts. NOTE 2.4b The mechanism for an image to reference and define a co-array on another image might vary according to the hardware. On a shared-memory machine, a co-array could be implemented as a section of an array of higher rank. On a distributed-memory machine with separate physical memory for each image, a processor might store a co-array at the same virtual address in each physical memory. [end NOTE] [somewhere later] Maybe add some example(s) to THIS_IMAGE in clause 13: "Consider a co-array declared as REAL :: A(10,20)[10,0:9,0:*] On image 5, THIS_IMAGE() has the value 5 and THIS_IMAGE(A) has the value [5,0,0]. For the same co-array on image 213, THIS_IMAGE(A) has the value [3,1,2]." [somewhere later] Maybe add example to IMAGE_INDEX: "Consider a co-array declared as REAL :: A(10,20)[10,0:9,0:*] On any image, IMAGE_INDEX(A,[3,1,2]) has the value 213.". 05-200r1: [19:4] 2.5.1 Name and designator, first paragraph, third sentence, After "component selectors" insert ", complex part selectors". 06-174r3: [19:5] 2.5.1, first paragraph, last sentence, after "array element selectors," add "image selectors,". 06-174r3: [28:4+] 3.3.1 Free source form, table of optional blanks in keywords, Add "END CRITICAL" to table. 06-175r2: [26:28+] 3.2.3 Operators, R721 , add new production "<> .XOR.". TR 19767: [28:5-] 3.3.1, last paragraph, list of "blanks are optional" keywords, insert "END PROCEDURE" and "END SUBMODULE" in the right place. 06-142: [28:5-] 3.3.1, last paragraph, list of "blanks are optional" keywords, insert "END BLOCK" in the right place. 06-146: [29:11-12] 3.3.1.3 Free form statement termination, second paragraph, Delete the fourth sentence, which reads 'A ";" shall not appear as the first nonblank character on a line.'. 06-146: [30:7] 3.3.2.3 Fixed form statement termination, second paragraph, fourth sentence, change "a line, except in character position 6." To "an initial line.". NOTE: This makes the sentence read 'A ";" shall not appear as the first nonblank character on an initial line.' 06-168r2: [31:0+] Add new subclause at the end of clause 3. "3.5 Macro processing 3.5.1 Macro definition A macro definition defines a macro. A defined macro may only be referenced by a USE statement, IMPORT statement, or macro expansion statement. A defined macro shall not be redefined. R313 <> [ ]... R314 <> DEFINE MACRO [ , ] :: [ ( [ ] ) ] C3nn (R314) A shall not appear more than once in a . R315 <> The DEFINE MACRO statement begins the definition of the macro . Appearance of an in the DEFINE MACRO statement explicitly gives the macro the specified attribute. Each is a macro dummy argument. A macro dummy argument is a macro local variable. R316 <> <> R317 <> MACRO :: R318 <> MACRO OPTIONAL :: R319 <> INTEGER [ ( [ KIND= ] ) ] C3nn (R317) A shall not be the same as the name of a dummy argument of the macro being defined. C3nn (R318) A shall be the name of a dummy argument of the macro being defined. C3nn (R319) If appears, when the macro is expanded it shall be of type integer, and have a non-negative value that specifies a representation method that exists on the processor. A macro type declaration statement specifies that the named entities are macro local variables of the specified type. If the kind is not specified, they are of default kind. A macro local variable that is not a macro dummy argument shall appear in a macro type declaration statement. R319a <> [ ]... R320 <> <> <> <> <> C3nn A statement in a macro definition that is not a or shall not appear on a line with any other statement. R321 <> R322 <> MACRO DO = , [ , ] C3nn (R322) A shall be a local variable of the macro being defined, and shall not be a macro dummy argument. R322a <> C3nn (R322a) A shall expand to an expression of type integer. R323 <> MACRO END DO A macro DO construct iterates the expansion of its enclosed macro body block at macro expansion time. The number of iterations is determined by the values of the expanded macro expressions in the MACRO DO statement. R324 <> [ ]... [ ] R325 <> MACRO IF ( ) THEN R326 <> MACRO ELSE IF ( ) THEN R327 <> MACRO ELSE R328 <> MACRO END IF R329 <> C3nn (R329) A macro condition shall expand to an expression of type logical. A macro IF construct provides conditional expansion of its enclosed macro body blocks at macro expansion time. Whether the enclosed macro body blocks contribute to the macro expansion is determined by the logical value of the expanded macro expressions in the MACRO IF and MACRO ELSE IF statements. R330 <> [ ]... [ && ] C3nn (R327) The first shall not be MACRO unless the second is not a keyword or name. R331 <> [ %% ]... Constraint: The concatenated textual s in a shall have the form of a lexical token. R332 is any lexical token including labels, keywords, and semi-colon. Constraint: && shall not appear in the last of a macro definition. Constraint: When a macro is expanded, the last processed shall not end with &&. R333 <> END MACRO [ ] Constraint: The in the END MACRO statement shall be the same as the in the DEFINE MACRO statement. R334 <> C3nn (R334) A shall expand to a scalar initialization expression. Macro expressions are used to control the behavior of the MACRO DO and MACRO IF constructs when a macro is being expanded. The type, type parameters, and value of a macro expression are determined when that macro expression is expanded. 3.5.2 Macro expansion 3.5.2.1 General Macro expansion is the conceptual replacement of the EXPAND statement with the Fortran statements that it produces. The semantics of an EXPAND statement are those of the Fortran statements that it produces. It is recommended that a processor be capable of displaying the results of macro expansion. It is processor-dependent whether comments in a macro definition appear in the expansion. It is processor-dependent whether continuations and consecutive blanks that are not part of a token are preserved. The process of macro expansion produces Fortran statements consisting of tokens. The combined length of the tokens for a single statement, plus inter-token spacing, shall not be greater than 256*130 characters. If a statement contains any character that is not of default kind, the maximum number of characters allowed is processor dependent. \begin{note} This length is so that the result of macro expansion can be formed into valid free form Fortran source, consisting of an initial line and 255 continuation lines, times 130 which allows for beginning and ending continuation characters (&) on each line. Also, breaking tokens across continuation lines in macro definitions and in EXPAND statements does not affect macro expansion: it is as if they were joined together before replacement. \end{note} R334 <> EXPAND [ ( ) ] C3nn (R334) shall be the name of a macro that was previously defined or accessed via use or host association. C3nn (R334) The macro shall expand to a sequence or zero or more complete Fortran statements. C3nn (R334) The statements produced by a macro expansion shall conform to the syntax rules and constraints as if they physically replaced the EXPAND statement prior to program processing. C3nn (R334) The statements produced by a macro expansion shall not include a statement which ends the scoping unit containing the EXPAND statement. C3nn (R334) If a macro expansion produces a statement which begins a new scoping unit, it shall also produce a statement which ends that scoping unit. C3nn (R334) If the EXPAND statement appears as the of an , it shall expand to exactly one that is not an , , , or . \obs{ C3nn (R334) If the EXPAND statement appears as a , it shall expand to exactly one that is not a , a , a , a , an , a , an , an , an , or an . } C3nn (R334) If the EXPAND statement has a label, the expansion of the macro shall produce at least one statement, and the first statement produced shall not have a label. C3nn (R334) A shall appear corresponding to each nonoptional macro dummy argument. C3nn (R334) At most one shall appear corresponding to each optional macro dummy argument. Expansion of a macro is performed by the EXPAND statement. If the EXPAND statement has a label, the label is interpreted after expansion as belonging to the first statement of the expansion. R335 <> [ = ] C3nn (R335) shall be the name of a macro dummy argument of the macro being expanded. C3nn (R334) The = shall not be omitted unless it has been omitted from each preceding in the . R336 <> R337 <> <> [ ] [ ] <> R338 is any lexical token except comma, parentheses, array constructor delimiters, and semi-colon. R339 <> ( [ ]... ) <> (/ [ ]... /) <> [ ]... R340 <> <> , Macro expansion processes any macro declarations of the macro definition, and then expands its macro body block. Any macro expressions in s are evaluated and the kinds of the macro variables thereby declared are determined for that particular expansion. Macro expansion of a macro body block processes each macro body construct of the macro body block in turn, starting with the first macro body construct and ending with the last macro body construct. Expansion of a statement within a macro body construct consists of three steps: (1) token replacement, (2) token concatenation, and (3) statement-dependent processing. Token replacement replaces each token of a macro body statement or macro expression that is a macro local variable with the value of that variable. In a macro expression, a reference to the PRESENT intrinsic function with a macro dummy argument name as its actual argument is replaced by the token \cf{.TRUE.} if the specified macro dummy argument is present, and the token \cf{.FALSE.} if the specified macro dummy argument is not present. Otherwise, the value of a macro dummy argument that is present is the sequence of tokens from the corresponding actual argument. The value of a macro dummy argument that is not present is a zero-length token sequence. The value of an integer macro variable is its minimal-length decimal representation; if negative this will produce two tokens, a minus sign and an unsigned integer literal constant. Token concatenation is performed with the %% operator, which is only permitted inside a macro definition. After expansion, each sequence of single tokens separated by %% operators is replaced by a single token consisting of the concatenated text of the sequence of tokens. The result of a concatenation shall be a valid Fortran token, and may be a different kind of token from one or more of the original sequence of tokens. Note 3.xx For example, the sequence 3 %% .14159 %% E %% + %% 0 forms the single real literal constant 3.14159E0. 3.5.2.2 Macro body statements Processing a macro body statement produces a whole or partial Fortran statement. A macro body statement that is either the first macro body statement processed by this macro expansion or the next macro body statement processed after a macro body statement that did not end with the continuation generation operator &&, is an initial macro body statement. The next macro body statement processed after a macro body statement that ends with && is a continuation macro body statement. An initial macro body statement that does not end with && produces a whole Fortran statement consisting of its token sequence. All other macro body statements produce partial Fortran statements, and the sequence of tokens starting with those produced by the initial macro body statement and appending the tokens produced by each subsequent continuation macro body statement form a Fortran statement. The && operators are not included in the token sequence. 3.5.2.3 The macro DO construct The macro DO construct specifies the repeated expansion of a macro body block. Processing the macro DO statement performs the following steps in sequence: \begin{enum} \item The initial parameter $m_1$, the terminal parameter $m_2$, and the incrementation parameter $m_3$ are of type integer with the same kind type parameter as the \si{macro-do-variable-name}. Their values are given by the first \si{macro-expr}, the second \si{macro-expr}, and the third \si{macro-expr} of the \si{macro-do-stmt} respectively, including, if necessary, conversion to the kind type parameter of the \si{macro-do-variable-name} according to the rules for numeric conversion (Table \ref{T:Numeric conversion and the assignment statement}). If the third \si{macro-expr} does not appear, $m_3$ has the value 1. The value of $m_3$ shall not be zero. \item The macro DO variable becomes defined with the value of the initial parameter $m_1$. \item The \tdef{iteration count} is established and is the value of the expression $(m_2-m_1 + m_3) / m_3$, unless that value is negative, in which case the iteration count is 0. \end{enum} After this, the following steps are performed repeatedly until processing of the macro DO construct is finished: \begin{enum} \item The iteration count is tested. If it is zero, the loop terminates and processing of the macro DO construct is finished. \item If the iteration count is nonzero, the macro body block of the macro DO construct is expanded. \item The iteration count is decremented by one. The macro DO variable is incremented by the value of the incrementation parameter $m_3$. \end{enum} 3.5.3.4 The MACRO IF construct The MACRO IF construct provides conditional expansion of macro body blocks. At most one of the macro body blocks of the macro IF construct is expanded. The macro conditions of the construct are evaluated in order until a true value is found or a MACRO ELSE or MACRO END IF statement is encountered. If a true value or a MACRO ELSE statement is found, the macro body block immediately following is expanded and this completes the processing of the construct. If none of the evaluated conditions is true and there is no MACRO ELSE statement, the processing of the construct is completed without expanding any of the macro body blocks within the construct. 3.5.3.5 Macro definitions Processing a macro definition defines a new macro. If a macro definition is produced by a macro expansion, all of the statements of the produced macro definition have token replacement and concatenation applied to them before the new macro is defined. 3.5.2.6 Examples Note 3.nn This is a macro which loops over an array of any rank and processes each array element. DEFINE MACRO loop_over(array,rank,traceinfo) MACRO INTEGER :: i BLOCK MACRO DO i=1,rank INTEGER loop_over_temp_%%i MACRO END DO MACRO DO i=1,rank DO loop_over_temp_%%i=1,size(array,i) MACRO END DO CALL impure_scalar_procedure(array(loop_over_temp_%%1 && MACRO DO i=2,rank ,loop_over_temp%i && MACRO END DO ),traceinfo) MACRO DO i=1,rank END DO MACRO END DO END BLOCK END MACRO Note 3.nn One can effectively pass macro names as macro arguments, since expansion of arguments occurs before analysis of each macro body statement. For example: DEFINE MACRO :: iterator(count,operation) DO i=1,count EXPAND operation(i) END DO END MACRO DEFINE MACRO :: process_element(j) READ *,a(j) result(j) = process(a(j)) IF (j>1) PRINT *,'difference =',result(j)-result(j-1) END MACRO EXPAND iterator(17,process_element) This expands into 17 sets of 3 statements: READ *,a(1) result(1) = process(a(1)) IF (1>1) PRINT *,'difference =',result(1)-result(1-1) READ *,a(2) result(2) = process(a(2)) IF (2>1) PRINT *,'difference =',result(2)-result(2-1) ... READ *,a(17) result(17) = process(a(17)) IF (17>1) PRINT *,'difference =',result(17)-result(17-1) Note 3.nn Using the ability to evaluate initialization expressions under macro control and test them, one can create interfaces and procedures for all kinds of a type, for example: DEFINE MACRO :: i_square_procs() MACRO INTEGER i MACRO DO i=1,1000 MACRO IF (SELECTED_INT_KIND(i)>=0 .AND. (i==1 .OR. SELECTED_INT_KIND(i)/=SELECTED_INT_KIND(i-1))) THEN FUNCTION i_square_range_%%i(a) RESULT(r) INTEGER(SELECTED_INT_KIND(i)) a,r r = a**2 END FUNCTION MACRO END IF MACRO END DO END MACRO". NOTE TO THE EDITOR: Change to etc in the above (this was changed by the co-array paper). 06-175r2: [33:5] 4. Types, second paragraph, last sentence, Change "and logical" to "logical, and bits". 06-175r2: [33:18] 4.1.1 Set of values, first sentence, After "as is the case for logical" insert "and bits". NOTE FROM THE EDITOR: Modified edit to add to the completely determined list. 06-175r2: [35:29] 4.4 Intrinsic types, first sentence, change "and logical" to ", logical, and bits". NOTE FROM THE EDITOR: Make this paragraph grammatical or an ISO-conformant list, currently it is bad. 06-175r2: [36:7+] 4.4, BNF R403 , add a new production "<> BITS []". 05-233r2: [36:20+] 4.4.1 "Integer type", Add a new paragraph after the first paragraph: "The processor shall provide at least one representation method with a decimal exponent range greater than or equal to 18." 05-231r4: [36:23] 4.4.1 Integer type, third paragraph, Append "The decimal exponent range of default integer shall be at least 5." 06-175r2: [37:1-3] 4.4.1 Integer type, BNF R411 , delete. [37:4-18] 4.4.1, BNF R412 to R415 , Delete these BNF rules, re-inserting them later (see [44:17+]). [37:19] 4.4.1, paragraph beginning "Binary, octal ...", delete first sentence. [37:20-21] 4.4.1, same paragraph, second sentence, Delete sentence, re-inserting later (see [44:17+]). [37:22-25] 4.4.1, last constraint (C410) "A ...", delete constraint. 05-232r1: [37:31-34] 4.4.2 "Real type", first paragraph, replace the last two sentences (which are "The decimal precision ... range requirements.") with "The decimal precision, decimal exponent range, and radix of an approximation method are returned by the intrinsic functions PRECISION (13.7.90), RANGE (13.7.96), and RADIX (13.7.93). The intrinsic function SELECTED_REAL_KIND (13.7.106) returns a kind value based on specified precision, range, and radix requirements." 05-233r2: [38:13+] 4.4.2 "Real type", after the 4th paragraph, add a new paragraph (that is immediately before "R416 <>..."), "The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall be at least 37. It is recommended that the decimal precision of default real be at least 6, and that its decimal exponent range be at least 37." 06-175r2: [44:17+] Immediately before 4.5 Derived types, insert new subclause "4.4.6 Bits type The <> has a set of values composed of ordered sequences of bits. The number of bits in the sequence is specified by the kind type parameter, KIND, which shall be greater than or equal to zero." NOTE FROM THE EDITOR: (same paragraph) the original had "The processor shall provide representation methods with kind type parameter values equal to every nonnegative integer less than or equal to four times NUMERIC_STORAGE_SIZE(13.8.2.7)." BUT IT SEEMS WE REALLY NEED BITS TO HANDLE ALL KINDS OF REAL ET AL, THEREFORE THIS IS CHANGED TO "The processor shall provide representation methods with kind type parameter values equal to every nonnegative integer less than or equal to a processor-determined limit. This limit shall be at least as large as the storage size, expressed in bits, of every supported kind of type integer, real, complex, and logical." NOTE: THIS WORDING MIGHT NEED FORTHER IMPROVEMENT. (same paragraph continuing) "Additional representation methods may be provided. The type specifier for the bits type uses the keyword BITS. If the kind type parameter is not specified for a bits variable, the default kind value is NUMERIC_STORAGE_SIZE, and the type specified is <>. R428a <> [ _ ] <> [ _ ] <> [ _ ]" Insert (from [37:4-18]) BNF R411 and constraints to R415, renumbering. Insert (from [37:20-21]) "The s ... equivalents." "If the optional kind type parameter is not specified for a boz literal constant, the kind value is assumed from the form of the constant. If the constant is a the kind value is the number of characters. If the constant is an the kind value is three times the number of characters. If the constant is a the kind value is four times the number of characters. Note 4.xx Even if a bits value is too large to fit into a single statement as a literal constant, it can be constructed by concatenation of bits named constants." NOTE FROM THE EDITOR: Reworded unnecessary blather as a note. It could be deleted as being sufficiently obvious (do we say this for character strings and arrays? the principle is the same). "Each digit of an octal constant represents three bits, and each hex digit of a hex constant represents four bits, according to their numerical representations as binary integers, with leading zero bits where needed. If a is specified for a boz literal constant and has a value greater than the number of bits specified by its digits, the constant is padded on the left (13.3) with enough zero bits to create a constant of kind . If the specified has a value smaller the number of bits specified by its digits, only the rightmost bits are used to determine the value of the constant." NOTE FROM THE EDITOR: Reworded to make more readable, use singular case, etc. "Note 4:15a Though the processor is required to provide bit kinds only up to four times NUMERIC_STORAGE_SIZE, it is expected that the actual size limit will be much larger, based on system capacity constraints. Use of BITS objects with KIND values equal to small integer multiples of NUMERIC_STORAGE_SIZE should result in more aggressive optimization.". TR 19767: [46:10] 4.5.1.1 Accessibility, third paragraph, after "the definition" insert ", and within its descendant submodules". TR 19767: [46:10+7] 4.5.1.1, Note 4.18, after "defined", insert ", and within its descendant submodules". 06-175r2: [46:20] 4.5.1.2 Sequence type, first textual paragraph, Before ", or a numeric sequence type" insert ", default bits". 06-174r3: [50:6] 4.5.3 Components, BNF R441 , Change "DIMENSION ( )" to "<> ". 05-273r3: [50:7+] 4.5.3 Components, BNF R441 , add new production "<> CONTIGUOUS" 06-174r3: [50:9+] 4.5.3, BNF R442 , After "[ ( ) ]" insert "[ ]". NOTE TO THE EDITOR: PROBABLY NEEDS TO BE ON A SEPARATE LINE WITH "smudge"s. 06-174r3: [50:10+] 4.5.4, after R442, add new BNF "R442a <> DIMENSION () <> DIMENSION [()] ". 05-279: [50:13-14] 4.5.3, Delete BNF R444 (it will reappear in a slightly different form in 4.5.3.4). 06-115r1: [50:18] 4.5.3, third constraint C438 after BNF R444 , Replace "the POINTER attribute is not" with "neither the POINTER nor ALLOCATABLE attribute is". [50:19] same constraint, Delete "shall be CLASS(*) or". 06-115r1: [50:21] 4.5.3, fourth constraint C439 after R444 , After "If the POINTER" Insert "or ALLOCATABLE". 06-174r3: [50:25+] 4.5.3, after the fifth constraint (C440) after R444, insert new constraints "C440a (R440) If a appears, it shall be a and the component shall have the ALLOCATABLE attribute. C440m A data component whose type has a co-array ultimate component shall be a nonpointer nonallocatable scalar and shall not be a co-array." NOTE FROM THE EDITOR: Reworded to use ultimate components, which works because allocatables are ultimate, because "subcomponent" is not defined for types, only for objects. Also simplified two constraints down to one, rewording it (mostly) into the positive. 05-273r3: [50:31+] 4.5.3, after C443 (R440) A component shall not have both the ...", Add a new constraint: "C443a (R440) If the CONTIGUOUS attribute is specified, the component shall be an array with the POINTER attribute.". 05-279: [50:36-40] 4.5.3, the two constraints immediately before R445 , Move these constraints to 4.5.3.4 as detailed in the edit for [53:5+]. 06-174r3: [51:17-20] 4.5.3.1, Array components, first paragraph, After "contains the DIMENSION" change "attribute" to "clause with a ", Change second "attribute" to "clause". NOTE FROM THE EDITOR: DIFFERS FROM THE PAPER. 06-174r3: [51:20+] 4.5.3.1, after the first paragraph, add new paragraph "A data component is a co-array if its contains a or its contains a DIMENSION attribute with a . If the contains a it specifies the co-rank; otherwise, the in the DIMENSION clause specifies the co-rank. NOTE FROM THE EDITOR: DIFFERS FROM THE PAPER. 05-279: [53:5+] 4.5.3.4 Default initialization for components, after the first paragraph, insert a new paragraph "A pointer variable or component is <> with a target if the pointer is type compatible with the target, they have the same rank, and the values of corresponding nondeferred type parameters are specified by initialization expressions that have the same value. R446a <> = <> => <> => R446b <> " Insert the moved C446 and C447 after the new R446b. After the moved constraints, insert new constraints: "C452a (R446a) If appears, shall be data-pointer-initialization compatible with it. C452b (R446b) The shall be an initialization target." 05-279: [53:7+] 4.5.3.4 Default initialization for components, after the second paragraph, insert new paragraphs "A is an <> if it has the TARGET attribute, either has the SAVE attribute or is declared in the main program, does not have the ALLOCATABLE attribute, and every subscript, section subscript, substring starting point, and substring ending point in the variable is an initialization expression. If appears for a data pointer component, that component in any object of the type is initially associated with the target or becomes associated with the target as specified in 16.4.2.1.1. If appears in for a procedure pointer component, that component in any object of the type is initially associated with the target or becomes associated with the target as specified in 16.4.2.1.1.". 06-115r1: [54:1-] 4.5.3.4, at the end of the last note 4.36 in this subclause, Append a sentence to the last paragraph, "Linked lists can also be constructed using allocatable components.". 05-279: [54:1-] 4.5.3.4, at the very end, insert the following note "Note 4.36a A pointer component of a derived type may be default-initialized to have an initial target. {{ TYPE NODE INTEGER :: VALUE = 0 TYPE (NODE), POINTER :: NEXT_NODE => SENTINEL END TYPE TYPE(NODE), SAVE, TARGET :: SENTINEL }}". TR 19767: [55:10] 4.5.3.6 Component accessibility, last paragraph (immediately before Note 4.38), after "definition", insert ", and within its descendant submodules". TR 19767: [55:10+17] 4.5.3.6, Note 4.40, last sentence, after "only within the module" insert ", and within its descendant submodules". Also, delete the MODULE and END MODULE statements from the example code. TR 19767: [56:1--] 4.5.3.6, Note 4.41, last sentence, after "definition" insert ", and within its descendant submodules". 05-196: [56:4] 4.5.4 Type-bound procedures, BNF R448 , delete the first "". TR 19767: [58:8] 4.5.4 Type-bound procedures, last paragraph, last sentence, after "definition" insert ", and within its descendant submodules". TR 19767: [59:23-24] 4.5.5.2 When finalization occurs, second paragraph, second sentence, - after "defined in a module" insert " or submodule,"; - after "referencing the module" insert "or accessing the submodule". 05-142: [59:24+] 4.5.5.2, after second paragraph, insert new paragraph "A nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it would become undefined due to termination of the BLOCK construct (16.5.6, item (19))." TR 19767: [60:4+5] 4.5.5.2, Note 4.48, second paragraph, - after the first "module" insert "or submodule"; - after the second "module" insert "or accessing the submodule". 06-158r2: [63:29-30] 4.5.9 Construction of derived-type values, third constraint (C484) after R459 , replace "If a ... is inheritance associated." by "If a \si{component-spec} is provided for an ancestor component, a \si{component-spec} shall not be provided for any component that is inheritance associated with a subcomponent of that ancestor component.". 06-158r2: [63:31-33] 4.5.9, fourth constraint (C485) after R459, before the first "component" insert "nonallocatable", before "another" insert "a subcomponent of" at the end, delete "or that has default initialization". 06-158r2: [64:15] 4.5.9, paragraph beginning "If a component with default initialization has no corresponding ...", append a new sentence "If an allocatable component has no corresponding \si{component-data-source}, then that component has an allocation status of unallocated.". (this is immediately before Note 4.57). 06-174r3: [67:8,11,12] 4.7 Construction of array values, Globally replace "" with "" and "" with "" throughout the whole standard (it only occurs these three times). 06-154r4: [67:18-19] 4.7 Construction of array values, replace R472 definition and the immediately following constraint C493 by "R472 <> 05-201r2: [71:9-12] 5.1 Type declaration statements, BNF R502 , Insert a second alternative "<> TYPE ( )" giving "R502 <> <> TYPE ( ) <> TYPE ( ) <> CLASS ( ) <> CLASS ( * )" 05-273r3: [71:20+] 5.1, BNF R503 , add new production "<> CONTIGUOUS" 06-174r3: [71:21] 5.1 Type declaration statements, BNF R503 , Change "DIMENSION ( )" to "". 06-174r3: [72:9] 5.1, BNF R504 , After "[ ( ) ]" insert "[]". NOTE TO THE EDITOR: BREAK INTO TWO LINES WITH "smudge"s. 06-174r3: [72:10+] 5.1, After BNF R504 , or somewhere anyway, add new production "R504a <> DIMENSION () <> DIMENSION [()] ". 05-279: [72:16+] 5.1, BNF R506 , add a third production and a constraint "<> => C505a (R506) If appears, shall be data-pointer-initialization compatible with it (\ref{D4:Default initialization for components}).". 06-174r3: [72:25+] 5.1, somewhere in some great list of constraints, probably in the DIMENSION attribute subclause actually?, insert new constraints "C510a (R501) A co-array that has the ALLOCATABLE attribute shall be specified with a that is a . C510b An entity whose type has a co-array ultimate component shall be a nonpointer nonallocatable scalar, shall not be a co-array, and shall not be a function result. C510m A co-array shall be a component or a variable that is not a function result.". NOTE FROM THE EDITOR: I rewrote C510b and C510c when it came out in discussion with JKR et al that functions returning objects with co-array components were not wanted. C510m is perhaps redundant with the edit to [72:33], though constraints on co-arrays are best handled in the co-array declaration subclause. 05-273r3: [72:29+] 5.1, after C512 (R501) If the POINTER attribute is specified..., Add new constraint: "C512a (R501) An entity that has the CONTIGUOUS attribute shall be an array pointer or an assumed-shape array." 06-174r3: [72:33] 5.1, massive constraint list, C514 about things not allowed to be PARAMETERs, after 'an allocatable entity,' add 'a co-array'. 06-174r3: [73:1+] 5.1, massive constraint list, after C517 about SAVE not being allowed for some things, add new constraints and notes "C517a (R501) The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared in the main program, or allocatable and declared in a non-recursive procedure. NOTE 5.2a An allocatable co-array is required to have the SAVE attribute in a recursive procedure because of the difficulties associated with defining the separate levels of recursion. Without the SAVE attribute, each would have a separate instance of the co-array and implicit synchronization would be required for each allocation and deallocation of each instance. Automatic co-arrays are not permitted; for example, the co-array WORK in the following code fragment is not valid: SUBROUTINE SOLVE3(N,A,B) INTEGER :: N REAL :: A(N)[*], B(N) REAL :: WORK(N)[*] ! Not permitted If this were permitted, it would require an implicit synchronization on entry to the procedure. Explicit-shape co-arrays that are not dummy arguments are required to have the SAVE attribute because otherwise they might be implemented as if they were automatic co-arrays. [end NOTE] C517b (R501) A co-array shall not have the POINTER attribute. C517c (R501) If the type specified has a co-array subcomponent, each entity in the shall have the SAVE attribute unless it is a dummy argument, declared in the main program, or declared in a non-recursive procedure. J3 TECHNICAL NOTE This is inconsistent. (1) We require the user to SAVE variables in non-recursive procedures if he wants the value to persist. (2) ALLOCATABLE arrays that are unsaved get deallocated in non-recursive procedures, not saved. (3) It requires SAVE in a MODULE, but not in a non-recursive procedure!?! If you are going to special-case ANYTHING, doing it for modules must be top priority, but it's better to avoid it entirely. NOTE 5.2b A co-array is permitted to be of a derived type with pointer or allocatable components. The target of such a pointer component is always on the same image. An allocatable component of a co-array need be allocated on an image only if it is referenced or defined. [end NOTE]". NOTE FROM THE EDITOR: Reworded slightly. Removed forward ref to 6.3.1 as it seemed to be irrelevant. 05-279: [73:15] NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS BOTH UNNECESSARY AND WRONG. 06-174r3: [74:20-] THIS EDIT IS MISPLACED "NOTE 5.3a Unless it is a dummy argument, a co-array has the same bounds and co-bounds on every image. NOTE 12.21b and NOTE 12.21c discuss the bounds and co-bounds of dummy argument co-arrays. [end NOTE]". NOTE TO THE EDITOR: Insert after the definition of co-bounds. 05-279: [74:33-34] 5.1, paragraph beginning "If is => ...", replace the paragraph with "If appears, the initial association status of the object is disassociated. If appears, the object is initially associated with the target.". 05-201r2: [75:7] Within the first paragraph of 5.1.1.1 TYPE replace "a derived" by "an intrinsic or derived". 05-201r2: [75:8] Replace "Where ... specifier" by "In a that specifies a derived type". 06-175r2: [76:5+] 5.1.1.2 Class, after the fourth paragraph, insert a new paragraph "A scalar entity of type bits is <> with a scalar entity of type bits, integer, real, complex, or logical if and only if both entities have the same size expressed in bits. J3 EDITORIAL NOTE. Consider whether this belongs in clause 4 with BITS, or clause 12 with TKR compatibility, or clause 4 with type compatibility. As stated, it doesn't have anything to do with CLASS (title of this subclause). J3 TECHNICAL NOTE (2). This leaves undefined whether entities of other types are bits compatible. NOTE: It has been suggested that (a) the definition is meant to be symmetric, and (b) complete. Perhaps something like "An entity is <> with another entity if and only if one is of type bits, the other is of type bits, integer, real, complex, or logical, and scalar entities of these types have the same size expressed in bits." It is not entirely obvious that this is correct, since the terms it is modelled on are not symmetric (and it is then used in those terms). "J3 TECHNICAL NOTE (3). This has wrecked generic resolution. It allows ambiguous procedures to be added to a generic set. BAD BAD BAD. Fixable by making bits only match bits in a generic setting, i.e. disable bits compatibility the same way we already disable sequence association. Other fixes possible. Note: If people want to use bits as a poor man's CLASS(*), for purposes of MPI compatibility, it is certainly not going to be straight- forward to fix this in any sort of consistent way. J3 TECHNICAL NOTE (4). Since the "kind" type parameter of bits is inherently a length type parameter (being the number of bits), it behooves us not to arbitrarily prevent variable length bits in the future. (FWIW, it does not look substantially more difficult to implement variable-length bits than fixed-length ones to me, and without adversely affecting the performance of known-length bit operations too.) This should be borne in mind while considering how to fix generics, for example. And maybe we should consider making "having a bits dummy" require an explicit interface.". NOTE FROM THE EDITOR: It is unclear whether the term "bits compatible" is useful or necessary. From the later edits I might surmise that people actually wanted to extend the concept of type compatibility (or "TK compatibility") but could not work out how to do it. In which case maybe that is what ought to be done. 06-175r2: [76:7-9] 5.1.1.2, sixth paragraph "An entity is type, kind ...", replace with "An entity is type, kind, and rank compatible, or <>, with another entity if both entities have the same rank, and either the first entity is type compatible with the second and the kind type parameters of the first entity have the same values as corresponding kind type parameters of the second, or the two entities are bits compatible. J3 TECHNICAL NOTE (2). The definition of bits compatible is not symmetric, so this does not have any determinable meaning.". NOTE FROM THE EDITOR: This makes the paragraph harder to read, too. I concur with Richard Maine's contention that we have no business mucking around with the type system in a minor revision. This is not close to correct. 05-273r3: [78:2-] After 5.1.2.4 BIND attribute for data entities, add a new subclause "5.1.2.4a CONTIGUOUS attribute The <> specifies that an entity is contiguous. An object is <> if it is not the real or imaginary part of an array of type complex, and is: (1) an object with the CONTIGUOUS attribute, (2) a scalar object, (3) a nonpointer array that is not assumed-shape, (4) an array allocated by an ALLOCATE statement, (5) an assumed-shape array that is argument associated with an array that is contiguous, (6) a pointer associated with a contiguous target, (7) an array with at most one element, or (8) a nonzero-sized array section (6.2.2) with the following properties: (a) Its base object is contiguous. (b) It does not have a vector subscript. (c) The elements of the section, in array element order, are a subset of the base object elements that are consecutive in array element order. (d) If the array is of type character and a appears, the specifies all of the characters of the (6.1.1). (e) Only its final has nonzero rank. An object is not contiguous if it is an array subobject, and (1) the object has two or more elements, (2) the elements of the object in array element order are not consecutive in the elements of the base object, (3) the object is not of type character with length zero, and (4) the object is not of a derived type that has no ultimate components other than zero-sized arrays and characters with length zero. It is processor-dependent whether any other object is contiguous. Note 5.10a If a derived type has only one component that is not zero-sized, it is processor-dependent whether a structure component of a contiguous array of that type is contiguous. That is, the derived type might contain padding on some processors. [end Note] Note 5.10b The CONTIGUOUS attribute allows a processor to enable optimizations that depend on the memory layout of the object occupying a contiguous block of memory. Examples of CONTIGUOUS attribute specifications are: REAL, POINTER, CONTIGUOUS :: SPTR(:) REAL, CONTIGUOUS, DIMENSION(:,:) :: D [end Note]" 06-174r3: [78:3-9] 5.1.2.5 DIMENSION attribute, first paragraph, replace whole paragraph with "The <> specifies that an entity is an array, a co-array, or both. If an appears, the entity is an array. If a appears, the entity is a . For an array, its specifies its rank or rank and shape. For a co-array, its specifies its co-rank or co-rank and co-bounds. The <> are given within square brackets in the co-array's declaration or allocation. If the co-rank is , the co-array has lower co-bounds , , upper co-bounds , , and co-extents , .". NOTE TO THE EDITOR: The last paragraph above actually belongs somewhere else. Maybe in the (missing?) subclauses about what the meaning of a actually is. 05-194r1: [78:13+] 5.1.2.5 DIMENSION attribute, BNF for R510 , after "<> ", insert "<> ". 05-234r2: (superceded by 06-174r3, see below) [78:14] 5.1.2.5 DIMENSION attribute, first constraint C541 replace "seven" with "fifteen", making the whole constraint: "C541 (R510) The maximum rank is fifteen." 06-174r3: [78:14] 5.1.2.5, first constraint, replace with R510a <> <> C541 The sum of the rank and co-rank of an entity shall not exceed fifteen. J3 TECHNICAL NOTE This does not work, because there are no semantics for the use of the syntax terms and out of their context. (In so far as there are semantics, they specify array bounds not co-array co-bounds.)". 05-194r1: [78:14+8+] 5.1.2.5 DIMENSION attribute, Note 5.11, append a new line of example: "REAL, PARAMETER :: V(0:*) = [0.1, 1.1] ! Implied-shape array" 05-194r1: [80:35+] Insert a new subclause immediately before 5.1.2.6 EXTERNAL attribute: "5.1.2.5.5 Implied-shape array An <> is a named constant that takes its shape from the in its declaration. An implied-shape array is declared with an . R516a <> [ : ] * C544a An implied-shape array shall be a named constant. The rank of an implied-shape array is the number of s in the . The extent of each dimension of an implied-shape array is the same as the extent of the corresponding dimension of the . The lower bound of each dimension is , if it appears, and 1 otherwise; the upper bound is one less than the sum of the lower bound and the extent." 05-210r2: [81:35] 5.1.2.7 INTENT attribute, fourth paragraph after C546 -- the one that begins "If no INTENT..." -- replace "associated actual argument" by "argument associated entity". TR 19767: [84:3] 5.1.2.12 PROTECTED attribute, second paragraph, first line, after "attribute," insert "or within any of its descendant submodules,". TR 19767: [84:14,16] 5.1.2.13 SAVE attribute, throughout second paragraph, change both occurrences of "module" to "module or submodule". 06-174r3: [85:6] 5.1.2.16 VOLATILE attribute, first paragraph, After "program" insert ", or by another image without synchronization". NOTE FROM THE EDITOR: Paper suggested inserting a contradictory sentence, so I fixed it to modify the main definition instead. 06-168r2: [86:10] 5.2.1 Accessibility statements, second constraint, Change "or namelist group" to "namelist group, or macro". 06-174r3: [86:21-22] 5.2.2 ALLOCATABLE statement, BNF R520 , replace with "R520 <> ALLOCATABLE [::] R520a <> [ ( ) ] [ ]". 05-273r3: [87:12+] After 5.2.4 BIND statement, add a new subclause "5.2.4a CONTIGUOUS statement R523a is CONTIGUOUS [::] The CONTIGUOUS statement specifies the CONTIGUOUS attribute (5.1.2.4a) for a list of objects." 06-172r2: [87:30] 5.2.5 DATA statement, BNF R527 , after " = \smudge", replace the rest of the production with Change DO bounds and step to initialization expressions: " \smudge , \smudge \smudge [, \smudge \smudge ] )" 06-154r4: [87:34] 5.2.5 DATA statement, replace R529 definition by "R529 <> " 06-174r3: [87:34+] 5.2.5 DATA statement, after BNF R529 ", add constraint "C552a A or shall not be a co-indexed variable.". 06-154r4: [88:4] 5.2.5, delete whole constraint "C556 ... The shall be a named variable." 06-172r2: [88:5-7] 5.2.5, constraint C557 "If ... shall involve as primaries ...", delete entire constraint. 06-172r2: [88:12-15] 5.2.5, constraint C561 "In an ... whose primaries ...", replace whole constraint with "C561 (R528) In an or that is a , any subscript shall be an initialization expression, and any primary within that subscript that is a shall be a DO variable of this or a containing .". 05-279: [88:26+] 5.2.5 DATA statement, BNF R532 , add a new penultimate production (after "<> ") "<> ". 05-279: [89:12] 5.2.5, fifth paragraph (beginning "The expanded sequence ..."), change "or " to ", initial data target, or ". 05-279: [89:14,16] 5.2.5, sixth and seventh paragraphs, insert "or " after "" twice. 05-279: [89:15] 5.2.5, sixth paragraph, second sentence, Change "The" to "If is , the". Change "pointer " to "data statement object". and append a new sentence to the paragraph "If is the corresponding shall be data-pointer-initialization compatible with the initial data target; the data statement object is initially associated with the target.". 06-175r2: [89:20-22] 5.2.5, eighth paragraph "If a is a <> DIMENSION [::] R535a <> () <> [()] This statement specifies the DIMENSION attribute (5.1.2.5) for each object named.". 06-174r3: [92:4-5] 5.2.13 TARGET statement, BNF R546 , replace BNF with "R546 <> TARGET [::] R546a <> [()] []". NOTE TO THE EDITOR: THE EXISTING TEXT FORGETS TO GIVE THE DIMENSION ATTRIBUTE WHEN AN APPEARS. OOPS. 06-174r3: [95:28+] 5.5 Storage association of data objects, after first paragraph, insert note "NOTE 5.36a The co-size of a co-array is not a constant, therefore co-arrays are not allowed in COMMON or EQUIVALENCE.". 06-174r3: [96:12+] 5.5.1 EQUIVALENCE statement, after the second constraint (C577) after BNF R556 , add new consttaint "C577a (R556) An shall not be a co-array or a subobject thereof.". [98:22] 5.5.2 COMMON statement, after R558 , second constraint (C588), Change ",or a result name" to ", a result name, or a co-array". 06-154r4: [103:6+] 6. Use of data objects, R601 , add new production "<> ". 06-154r4: [103:7+] 6., after C601, insert new constraint and following paragraph "C601a (R601) The shall be a reference to a function that has a pointer result. A variable is either the data object denoted by \si{designator} or the target of \si{expr}.". 05-200r1: [103:13+] 6 Use of data objects, BNF for R603 , after "<> " insert a new line "<> ". 06-174r3: [105:2] 6.1.2 Structure components, BNF R613 , append to production "[ ]". 06-174r3: [105:9+] 6.1.2, after the fifth constraint (C613) after BNF R613 , add constraints and note "C613a (R613). If appears and is an array, () shall appear. C613b (R613) A that is a co-indexed object shall not be of a type that has a pointer ultimate component. NOTE 6.3a This restriction is needed to avoid a disallowed pointer assignment for a component, such as Z[P] = Z ! Not allowed if Z has a pointer component Z = Z[P] ! Not allowed if Z has a pointer component" NOTE FROM THE EDITOR: Rewrote C613b because these things are not passable as actual arguments either, so they don't appear to be usable at all. So I made them not exist. J3 TECHNICAL NOTE (1) Is Z[P] = Z allowed if Z has an allocatable component? This would imply remote (re)allocation, which I was told was bad when I asked why we were prohibiting "array[i]" forcing it to be "array(:)[i]. Also, constraint (C633a) in ALLOCATE prevents explicit remote allocation. If the answer is that remote reallocation is fine in this instance, we need to make that consistent (including allowing explicit remote allocation). Or if it is bad, we need to remove it consistently. Subgroup say they want to allow this, but require allocatable components in Z[P] to have the same shape as those in Z, removing the auto realloc. The editor disagrees that this is an obviously "good" technical fix; see discussion under assignment. J3 TECHNICAL NOTE (2) If allocatable components are fine for remote reallocation, the constraint above is fine as far as it goes, but the general prohibition cannot be a constraint, because an allocatable component could contain pointer components. Whether these are subcomponents depends on whether they exist, i.e. whether the allocatable component is allocated, i.e. a runtime requirement.". ". NOTE FROM THE EDITOR: C613a is probably better without the parentheses! I changed C613b to avoid "subcomponent" of a type. Types don't have them. 05-200r1: [106:2+] Immediately before 6.1.3 Type parameter inquiry, insert new subclause: "6.1.2a Complex parts A <> is used to designate the real or imaginary part of a complex data object, independently of the other part. R614a <> % RE <> % IM C615a (R614a) The shall be of complex type. If is %RE it designates the real part of . If it is %IM it designates the imaginary part of . The type of a is real, and its kind and shape are those of the . Note 6.6a The following are examples of complex part designators: impedance%re !-- Same value as REAL(impedance) fft%im !-- Same value as AIMAG(fft) x%im = 0.0 !-- Sets the imaginary part of X to zero 05-260r1: [107:12+] Insert new BNF production for R617 : "<> " 05-260r1: [107:14] In the first constraint (C618) for R617 , Change "rank or" to "rank, the is a that is an array, or" 05-234r2: [108:6+] 6.2.2.2 Array element order, Table 6.1, In the second to bottom box: In the "Rank" column, change "7" to "15" In the Subscript bounds column, change the subscripts on the final j and k from "7" to "15" In the Subscript list column, change the subscript on the final s from "7" to "15" In the Subscript order value column, in the fifth line, change the subscripts on s and j from "7" to "15", and the subscript on d from "6" to "14"; in the sixth line, change the subscript on the first d from "5" to "13". In the bottom (Notes) box, in the last line, change "7" to "15". 06-174r3: [110:2-] Immediately before 6.3 Dynamic association, add new subclause "6.2a Image selectors An <> specifies the image index for co-array data. R622a <> R622b <> The number of co-subscripts shall be equal to the co-rank of the object. The value of a co-subscript in an image selector shall be within the bounds for its co-dimension. An image selector shall specify an image whose index is in the range 1, ..., NUM_IMAGES(). NOTE 6.15a For example, if there are 16 images and the co-array A is declared REAL :: A(10)[5,*] A(:)[1,4] is valid because it specifies image 16, but A(:)[2,4] is invalid because it specifies image 17. [end NOTE]". 06-137: [110:15+] 6.3.1 ALLOCATE statement, BNF R624 , insert another production "<> MOLD = " 06-174r3: [110:20] 6.3.1, BNF R628 , after "[ ( ) ]" insert in the same production "[ ]". NOTE TO THE EDITOR: multi-line smudge will be needed. 06-174r3: [111:5+] 6.3.1, After BNF R632 , add new production "R632a <> [,] [:]* R632b <> [ : ] " 06-174r3: [111:17] 6.3.1, seventh constraint ("C628 ... is an array.") after R632, Append new sentence to constraint "An shall appear if and only if the is a co-array.". 06-174r3: [111:19] 6.3.1, eighth constraint (C629) after R632, Append new sentence to constraint "The number of s in an shall be one less than the co-rank of the .". 06-137: [111:21-23] 6.3.1, antepenultimate and penultimate constraints C631 and C632 in the block of constraints after R632 , Replace these two constraints "C631 (R623) If SOURCE= appears ... same rank as ." With "C631 (R623) At most one of SOURCE=, MOLD=, and shall appear. C632 (R623) Each shall be type compatible (5.1.1.2) with . If SOURCE= appears, shall be a scalar or have the same rank as each ." [111:25+] 6.3.1, after the block of constraints following BNF R632, Add new constraint and note "C633a (R629) An shall not be a co-indexed object. NOTE 6.15b If a co-array is of a derived type that has an allocatable component, the component shall be allocated by its own image: TYPE(SOMETHING), ALLOCATABLE :: T[:] ... ALLOCATE(T[*]) ! Allowed - implies synchronization ALLOCATE(T%AAC(N)) ! Allowed - allocated by its own image ALLOCATE(T[Q]%AAC(N)) ! Not allowed, because it is not ! necessarily executed on image Q. [end NOTE]". NOTE FROM THE EDITOR: I changed the name of the component to "AAC", because "PTR" is an astonishly poor name for an ALLOCATABLE component... 06-137: [111:32-36] 6.3.1, third paragraph after the block of constraints after R632, Replace whole paragraph "The optional ... its declared type." With "If is specified, each is allocated with the specified dynamic type and type parameter values; if is specified, each is allocated with the dynamic type and type parameter values of ; otherwise, each is allocated with its dynamic type the same as its declared type." 06-174r3: [111:36] 6.3.1, append to (replaced by 06-137) third paragraph "The dynamic type shall not have a co-array ultimate component. J3 TECHNICAL NOTE (minor) It is worth considering how this dynamic type could ever have a co-array subcomponent. In particular, we should constrain this against being such a type. (major) This is a runtime problem which cannot be avoided by the user in any systematic way. It is a very bad idea to design the language so that "bad things happen" when the user is not in any position to detect that a bad thing might happen. The easy solution is (1) to prohibit type extension from adding co-array components, and (2) to constrain the declared type of from having any co-array ultimate components. Since co-array components are really really special (like, something with a co-array component cannot be pointed to) it does not seem too unreasonable for them not to be includable via type extension.". 06-137: [111:37-39] 6.3.1, fourth paragraph after the constraints after R632, Replace whole paragraph "When an ALLOCATE ... error condition occurs." With "If appears and the value of a type parameter it specifies differs from the value of the corresponding nondeferred type parameter specified in the declaration of any , an error condition occurs. If the value of a nondeferred length type parameter of an differs from the value of the corresponding type parameter of , an error condition occurs." 06-137: [112:10+] 6.3.1, immediate before Note 6.19 "An example of an ALLOCATE statement in which the value ..." Insert new paragraph and Note: "If MOLD= appears and is a variable, its value need not be defined. NOTE 6.18a The can be an array or scalar independently of whether an is an array or a scalar. For MOLD=, only the dynamic type and type parameter values of are relevant; its rank, shape, and value are not." TR 19767: [113:18] 6.3.1.1 Allocation of allocatable variables, penultimate paragraph, third sentence replace "module or a subobject thereof" by "module or submodule, or a subobject thereof,". 06-174r3: [113:21+] 6.3.1.1 Allocation of allocatable variables, at the end, insert new paragraphs and note: "The value of each and each in an shall be the same on each image. If an specifies a co-array, its dynamic type and the values of each length type parameter shall be the same on each image. There is implicit synchronization of all images in association with each ALLOCATE statement that involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement is delayed until all other images have executed the same statement the same number of times. NOTE 6.19a When an image executes an ALLOCATE statement, communication is not necessarily involved apart from any required for synchronization. The image allocates its co-array and records how the corresponding co-arrays on other images are to be addressed. The processor is not required to detect violations of the rule that the bounds are the same on all images, nor is it responsible for detecting or resolving deadlock problems (such as two images waiting on different ALLOCATE statements). [end NOTE]". COMMENT FROM THE EDITOR: I deleted the redundant (and not quite properly worded) "The segments executed before the statement on any image precede the segments executed after the statement on any image.", since this is not where ordering is defined, nor do we mention this effect for certain other implicit synchronisations. COMMENT FROM THE EDITOR: Why does this say anything about what synchronisation does anyway? It should just say that there *IS* implicit synchronisation and give a forward ref to the synchronisation subclause which says what that means. Particularly since: (a) the text is duplicated for explicit DEALLOCATE and (b) the effect is not specified for implicit DEALLOCATE. 06-142: [115:8+] 6.3.3.1 Deallocation of allocatable variables, after second paragraph, Insert new paragraph "When a BLOCK construct terminates, an allocatable variable that is a named local variable of the construct retains its allocation and definition status if it has the SAVE attribute; otherwise it is deallocated." TR 19767: [115:9-10] 6.3.3.1 Deallocation of allocatable variables, third paragraph (the one after Note 6.23), throughout, replace both occurrences of "module" by "module or submodule". 05-278r2: (modified by 06-154r4:) [116:12] 6.3.3.1, near the end, paragraph beginning "When an intrinsic assignment ...", replace "" by "variable". 06-174r3: [116:19-] 6.3.3.1 Deallocation of allocatable variables, at the end, insert new paragraphs and note "There is implicit synchronization of all images in association with each DEALLOCATE statement that involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement is delayed until all other images have executed the same statement the same number of times. There is also an implicit synchronization of all images in association with the execution of a RETURN or END statement that causes the deallocation of a co-array or a subcomponent that is a co-array." COMMENT FROM THE EDITOR: This is both overly specificative and insufficiently. NOTE TO THE EDITOR: Integration with 06-142 edit [115:8+] suggests replacing the last para above with "There is also an implicit synchronization of all images in association with the deallocation of a co-array or co-array subcomponent caused by the execution of a RETURN or END statement or the termination of a BLOCK construct.". 06-175r2: [119:2] 7.1.1.4 Level-3 expressions, first paragraph, Replace "character operator " with "character operator and bits concatenation operator ". NOTE FROM THE EDITOR: Probably should be "character and bits concatenation operator " (in which case, refer to the character // as the "character concatenation operator" not just the "character operator" throughout) 06-175r2: [120:2] 7.1.1.6 Level-5 expressions, first paragraph, After "logical" insert "and bits". 06-175r2: [120:12+] 7.1.1.6, BNF R721 , add new production "<> .XOR.". 06-175r2: [121:7+] 7.1.2 Intrinsic operations, table 7.1, replace boxes 3-7 with (redundant headings supplied for clarity only): "Intrinsic operator Type of Type of Type of [] ---------------------------------------------------------------- // C C C B B B ---------------------------------------------------------------- I I,R,Z,B L,L,L,L .EQ. .NE. R I,R,Z,B L,L,L,L ==, /= Z I,R,Z,B L,L,L,L B I,R,Z,B L,L,L,L C C L ---------------------------------------------------------------- I I,R,B L,L,L .GT.,.GE.,.LT.,.LE. R I,R,B L,L,L >, >=, <, <= B I,R,B L,L,L C C L ---------------------------------------------------------------- .NOT. L,B L,B ---------------------------------------------------------------- .AND.,.OR.,.XOR.,.EQV., L L L .NEQV. B B,I B,B I B,I B,B". Then, in the Note at the bottom of the table, Replace "and L" with "L, and B", Replace "and logical" with "logical, and bits". 06-175r2: [121:17-25] 7.1.2, fifth and sixth paragraphs "A <> is the intrinsic operation for which the is (//) and both operands are of type character. The operands shall have the same kind type parameter. The <> is the operator in a character intrinsic operation." NOTE FROM THE EDITOR: Changed "A ... an" to "The ... the", since there is only one. "A <> is an intrinsic operation for which the is .AND., .OR., .XOR., .NOT., .EQV., or .NEQV. and both operands are of type logical. A <> is the operator in a logical intrinsic operation. A <> is an intrinsic operation for which the is //, .AND., .OR., .XOR., .NOT., .EQV., or .NEQV. and at least one operand is of type bits. A <> is the operator in a bits intrinsic operation. For bits intrinsic operations other than concatenation (//), the two operands may be of different types or different kind type parameters. The effect is as if each operand that differs in type or kind type parameter from those of the result is converted to the type and kind type parameter of the result before the operation is performed." NOTE FROM THE EDITOR: Reworded above paragraph to be more like the other operations. "A <> is an that is .EQ., .NE., .GT., .GE., .LT., .LE., ==, /=, >, >=, <, or <=. A <> is an intrinsic operation for which the is a relational intrinsic operator. A <> is a relational intrinsic operation for which both operands are of numeric type. A <> is a relational intrinsic operation for which both operands are of type character. The kind type parameters of the operands of a character relational intrinsic operation shall be the same. A <> is a relational intrinsic operation for which at least one of the operands is of type bits.". NOTE FROM THE EDITOR: See edit for [135:22-] for additional material potentially to be appended here. 06-175r2: [123:24+] 7.1.4 Type, type parameters, and shape of an expression, add a syntax term for a bits expression: NOTE FROM THE EDITOR: REJECTED. THIS SYNTAX TERM IS NEVER USED. ADDING UNUSED SYNTAX TERMS IS A POINTLESS EXERCISE IN FUTILITY. 06-175r2: [124:24] 7.1.4.2 Type, type parameters, and shape of the result of an expression, numbered list, item (2), change "or logical" to "logical, or bits". 06-175r2: [124:44+] 7.1.4.2, numbered list, after item (5) "For an expression ... is a logical intrinsic binary operator ...", insert new item "(5a) For an expression // where both operands are of type bits, the kind type parameter of the result is the sum of the kind type parameters of the operands. (5b) For an expression where is a bits intrinsic binary operator other than //, the type of the expression is bits and the kind type parameter of the expression is the maximum of BITS_KIND() and BITS_KIND().". NOTE FROM THE EDITOR: Simplified big paragraph, breaking it into two small. 06-175r2: [124:46+] 7.1.4.2, at the end of the subclause, add a new constraint "C709a The kind type parameter for the result of a bits concatenation operation expression shall be a bits kind type parameter value supported by the processor." NOTE FROM THE EDITOR: Requires bits covering all intrinsic type sizes. 06-175r2: [125:41] 7.1.6 Specification expression, second numbered list, Replace "function KIND" with "functions KIND and BITS_KIND". 06-140r1: [126:3-4] 7.1.6 Specification expression, second numbered list, After "type parameter inquiry (6.1.3)," delete "or", After "IEEE inquiry function (14.9.1)," insert "or", Add new list item "(9) the function C_SIZEOF from the intrinsic module ISO_C_BINDING.". 06-167r1: [126:3-4+] 7.1.6, second numbered list, append new list item "(10) the COMPILER_VERSION or COMPILER_OPTIONS inquiry functions from the intrinsic module ISO_FORTRAN_ENV (13.8.2.1A, 13.9.2.1B)." NOTE TO THE EDITOR: Reformatted to conform to ISO guidelines. Be careful with the disjunction. 05-279: [126:27-29] 7.1.7 Initialization expression, numbered list, replace the third item by "(3) A structure constructor where each corresponding to (a) An allocatable component is a reference to the intrinsic function NULL, (b) A pointer component is a reference to the intrinsic function NULL or an initialization target, and (c) Any other component is an initialization expression,". 06-172r2: [127:16+] 7.1.7, numbered list, after "A kind type parameter ...", insert new item, " (9a) A within a ,". 06-143: [129:2] 7.1.8 Evaluation of operations, immediately before Note 7.13, Delete sentence "The processor may perform the element-by-element operations in any order.". 06-143: [129:4] 7.1.8, last paragraph, After "the operation is performaned element-by-element" Delete ", in any order,". 06-143: [129:4+] 7.1.8, at the end, Insert new note "NOTE 7.13a If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.7), the element operations may be performed simultaneously or in any order.". 06-174r3: [129:11-] 7.1.8.1 Evaluation of operands, at the very end (after Note 7.15), insert "If a statement contains a function reference in a part of an expression that need not be evaluated, no invocation of that function in that part of the expression shall execute an image control statement other than CRITICAL or END CRITICAL. NOTE 7.15a This restriction is intended to avoid inadvertant deadlock caused by optimization.". 06-174r3: [not at 130:1-] 7.1.8.2 Integrity of parentheses, at the end after note 7.16, add "During an execution of a statement that contains more than one reference to a procedure, image control statements other than CRITICAL or END CRITICAL shall be executed in at most one of the procedures invoked.". COMMENT FROM THE EDITOR: This should be put into the synchronisation subclause. 06-175r2: [132:9+] Immediately before 7.1.8.7 Evaluation of a defined operation, insert new subclause "7.1.8.5a Evaluation of bits intrinsic operations The rules given in 7.2.5 specify the interpretation of bits intrinsic operations. Once the interpretation of an expression has been established in accordance with those rules, the processor may evaluate any other expression that is computationally equivalent, provided that the integrity of parentheses in any expression is not violated. Note 7.23a For example, for the variables B1, B2, and B3 of type bits, the processor may choose to evaluate the expression B1 .xor. B2 .xor. B3 as B1 .xor. (B2 .xor. B3) [end Note] Two expressions of type bits are computationally equivalent if their values are equal for all possible values of their primaries.". 06-175r2: [132:18] 7.2 Interpretation of operations, second sentence, change "and logical" to "logical, and bits". NOTE TO EDITOR: FIX EXISTING EXECRABLE STYLE AT [135:1-4,9-12]. 06-175r2: [135:22-] 7.2.3 Relational intrinsic operations, at the end, append new paragraphs "A bits relational intrinsic operation is interpreted as having the logical value true if and only if the values of the operands satisfy the relation specified by the operator. For a bits relational intrinsic operation where the operands are both of type bits and of the same kind type parameter, and are equal if, at each bit position, their corresponding bits are the same, or they both have kind type parameter value of zero; otherwise they are unequal. If and are unequal, and the leftmost unequal corresponding bit of is 1 and is 0 then is considered to be greater than ; otherwise is considered to be less than . If both and are of type bits but have unequal kind type parameters, the operand with the smaller kind type parameter is treated as if it were padded on the left with the number of 0 bits required to make the number of bits in each operand the same. If one of the operands is not of type bits, that operand, , is converted to type bits with a kind type parameter of BITS_KIND() before the operation is evaluated." NOTE FROM THE EDITOR: Wow, what a lot of words. I'm sure we don't need that many. Also, any conversion should probably be in 7.1.2 where the rest of them are (yes, I know the existing relational operators get this wrong... though I am not sure why they do that). Here is my suggestion: [121:25] Add a new paragraph after definition of "bits relational operation", "If both operands of a bits relational operation do not have the same kind type parameter, the operand with the smaller kind type parameter is converted to the same kind as the other operand. If one operand of a bits relational operation is not of type bits, it is converted to type bits with the same kind type parameter as the other operand. Any conversion takes place before the operation is evaluated." [135:22-] Instead of the second paragraph above, insert the following: "For a bits relational intrinsic operation, and are equal if and only if each corresponding bit has the same value. If and are not equal, and the leftmost unequal corresponding bit of is 1 and is 0 then is greater than ; otherwise is less than .". END OF NOTE: I will make this change. NOTE TO THE EDITOR: The existing text is very sloppy about conversions, about half of the places rigorously saying "according to the rules of intrinsic assignment", the other half just hand-wavingly saying "converted". We should probably have a subclause "Conversions" which covers everything (not just intrinsic assignment!) and everything should reference that subclause. 06-175r2: [135:28+] 7.2.4 Logical intrinsic operations, table 7.5, Add a new row following the entry for .OR. ".XOR. Logical nonequivalence .XOR. True if either or is true, but not both.". NOTE TO THE EDITOR: .EQV. SHOULD PRECEDE .NEQV. IN THIS TABLE. 06-175r2: [136:2-] 7.2.4, at the end, after table 7.6, insert new paragraph "The values for the logical intrinsic operation .XOR. are identical to those for .NEQV. .". 06-175r2: [136:2-] Immediately before 7.3 Precedence of operators, add new subclause "7.2.5 Bits intrinsic operations Bit operations are used to express bitwise operations on sequences of bits, or to concatenate such sequences. Evaluation of a bits operation produces a result of type bits. The permitted types of operands of the bits intrinsic operations are specified in 7.1.2. The bits operators and their interpretation when used to form an expression are given in Table 7.6a, where denotes the operand of type bits to the left of the operator and denotes the operand of type bits to the right of the operator." NOTE FROM THE EDITOR: I struck the second sentence of this paragraph as it was unnecessary. The whole point of converting the operands before doing the operation is so that you only have to define the operation for operands of the same type and kind. " Table 7.6a Interpretation of the bits intrinsic operators --------------------------------------------------------------------- Operator Representing Use of operator Interpretation --------------------------------------------------------------------- // concatenation // concatenate with .NOT. bitwise not .NOT. bitwise not of .AND. bitwise and .AND. bitwise and of and .OR. bitwise or .OR. bitwise or of and .XOR. bitwise .XOR. bitwise exclusive or of exclusive or and .EQV. bitwise .EQV. bitwise equivalence of equivalence and .NEQV. bitwise .NEQV. bitwise nonequivalence nonequivalence of and -------------------------------------------------------------------- The leftmost KIND() bits of the result of the bits concatenation operation are the value of and the rightmost KIND() bits of the result are the value of . For a bits intrinsic operation other than //, the result value is computed separately for each pair of bits at corresponding positions in each operand. The value of each bit operation, for bits denoted and are given in Table 7.6b. Table 7.6b The values of bitwise operations involving bits intrinsic operators -------------------------------------------------------------------- .NOT. .AND. .OR. .XOR. 0 0 1 0 0 0 0 1 0 0 1 1 1 0 1 0 1 1 1 1 0 1 1 0 -------------------------------------------------------------------- The values for the bits intrinsic operation .NEQV. are identical to those for .XOR. . The values for the bits intrinsic operation .EQV. are identical to those for .NOT. ( .XOR. ).". NOTE FROM THE EDITOR: That's really cute, but I'm inclined to add a .EQV. column at least. Note that table 7.6 includes columns for both .EQV. and .NEQV., it doesn't make the user have to read the text. 06-175r2: [136:5+] 7.3 Precedence of operators, Table 7.7 Categories ..., In the column labeled "Category of operation", replace "Logical" with "Logical or Bits" four times. In the penultimate row of the same table, replace ".EQV. or .NEQV." with ".XOR., .EQV., .NEQV.". NOTE TO THE EDITOR: Eliminate "or" elsewhere in this table in favour of comma (currently one entry uses comma, 4 entries use or, so it is not consistent). 05-278r2: (superceded by 06-154r4:) [138:12-13] 7.4.1.1 General form, BNF R734 and following constraint C715. Leave as is, except: Editorial note: Maybe delete "in an " as being unnecessary. 05-278r2: (superceded by 06-154r4:) [138:15+] 7.4.1.1, at the end, do not add a new final paragraph. 05-198r1 without 05-278r2: [138:18] 7.4.1.2 Intrinsic assignment statement, end of first paragraph, replace " shall not be polymorphic" by "if is polymorphic it shall be allocatable". 05-198r1 with 05-278r2: (modified by 06-154r4:) [138:18] 7.4.1.2, end of first paragraph, replace " shall not be polymorphic" by "if the variable is polymorphic it shall be allocatable". 05-278r2 without 05-278r1: (modified by 06-154r4:) [138:18] 7.4.1.2, end of first paragraph, replace "" by "the variable". 05-278r2: (modified by 06-154r4:) [138:19-139:1] 7.4.1.2, numbered list, replace " by "the variable" all 4 times. 06-174r3: [138:19+] 7.4.1.2, numbered list, after item (1), insert new item "(1a) If is a co-indexed object, it shall not be of a type that has an allocatable ultimate component, J3 TECHNICAL NOTE 06-174r3 had no edit about this at all; when it came up in discussion with JKR et al they suggested making a runtime requirement that the types and shapes of the allocatable components must match; however, that would be very unsafe. Since the only safe way of programming such an assignment would be to avoid the intrinsic assignment altogether, we should not allow the intrinsic assignment in this case. Furthermore, giving different semantics to intrinsic assignment when a component is a co-indexed object is a bad idea - it will confuse the users - better to disallow the discrepant inconsistency. The fact that this inherently unsafe idea affects cross-image variables with all the fun of race conditions and other goodies to make debugging impossible simply underlines that this is a bad idea." 06-174r3: [138:20-21] 7.4.1.2, numbered list, item (2), Replace "Either ... shall conform" with "The shapes of the variable and shall conform unless the variable is an allocatable array that has the same rank as and is neither a co-array nor a co-indexed object". COMMENT FROM THE EDITOR: Modified in consultation with JKR et al. 06-174r3: [138:21] 7.4.1.2, numbered list, second item, Delete "and" at the end of this item, After the item insert new item "(2a) If the variable is an allocatable co-array or co-indexed object, its dynamic type shall be the same as that of , and J3 TECHNICAL NOTE Since this almost completely guts the polymorphic assignment feature for co-things, why not just disallow polymorphic assigment altogether for co-things? That would be *MUCH SAFER*, and result in the loss of almost no functionality (one can point a non-polymorphic pointer at the polymorphic co-thing if one wishes to do the required assignment. Furthermore, doing that would still allow co-arrays to be extended later on to "do the right thing" for polymorphic assignment.". COMMENT FROM THE EDITOR: Modified heavily since the paper's insertion was inappropriate (this is about dynamic types, whereas the paper said to insert it into the middle of a requirement for declared types...). 05-198r1: (modified by 06-154r4:) [139:1] 7.4.1.2 Intrinsic assignment statement, numbered list, beginning of item (3), replace "The" by "If is polymorphic it shall be type compatible with and have the same rank. Otherwise the". CONFLICT RESOLUTION: with [05-278r2], this edit becomes item (3), replace "The" by "If the variable is polymorphic it shall be type compatible with and have the same rank. Otherwise the". 05-278r2: (modified by 06-154r4:) [139:2+1-6] 7.4.1.2 Intrinsic assignment statement, Table 7.8, heading and "other character" lines, replace "" by "the variable" both times. 06-175r2: [139:2+2-7] 7.4.1.2, Table 7.8, In the "Type of " column, Change ", complex" to ", complex, bits" three times. Change "logical" to "logical, bits" once. After the "logical" row, insert a new row "bits integer, real, complex, logical, bits". NOTE FROM THE EDITOR: I've made bits consistently the last intrinsic type here, just as it is elsewhere. 06-175r2: (taking 06-154r4 into account): [139:6] 7.4.1.2, paragraph after table 7.8, before the last sentence ("A <> is an intrinsic assignment statement for which either the variable or is of type bits.". 05-278r2 without 05-198r1: (modified by 06-154r4:) [139:2+8-11] 7.4.1.2, Table 7.8, first line of the "derived type" row onwards, replace "" by "the variable" both times. 05-198r1: [139:2+8-11] 7.4.1.2, Table 7.8, first line of the "derived type" row onwards, - delete "and kind parameters" and the semicolon. - then delete the last three lines of Table 7.8 (which reappear in the next edit).] 05-198r1 without 05-278r2: [139:3-] 7.4.1.2, numbered list, insert a fourth item: "(4) If is of derived type each length type parameter of shall have the same value as the corresponding type parameter of unless is allocatable and its corresponding type parameter is deferred, and each kind type parameter of shall have the same value as the corresponding type parameter of ." NOTE FROM THE EDITOR: This insertion should be at 2+0-, i.e. before the table, so that the table doesn't break up the list. 05-198r1 with 05-278r2: (modified by 06-154r4:) [139:3-] 7.4.1.2, numbered list, insert a fourth item: "(4) If the variable is of derived type each length type parameter of the variable shall have the same value as the corresponding type parameter of unless the variable is allocatable and its corresponding type parameter is deferred, and each kind type parameter of the variable shall have the same value as the corresponding type parameter of ." NOTE FROM THE EDITOR: This insertion should be at 2+0-. 05-278r2: (modified by 06-154r4:) [139:3-12] 7.4.1.2, the three paragraphs following table 7.8, replace "" by "the variable" all 7 times. 05-278r2: (modified by the editor, in the spirit of 06-154r4:) [139:15-19] 7.4.1.3 Interpretation of intrinsic assignments, first paragraph, replace all occurrences of as follows: [139:16] replace both occurrences of "" by "the variable" [139:18] replace the first "" by "the variable", [139:19] replace both occurrences of "" by "the variable". NOTE FROM THE EDITOR: 06-154r4 did not change this edit, but it is necessary. 05-278r2: (modified by 06-154r4:) [139:21] 7.4.1.3, second paragraph, replace both occurrences of "" by "the variable". 05-278r2: (modified by 06-154r4:) [139:22-23] 7.4.1.3, third paragraph, replace "" by "the variable" all 3 times. 05-198r1 without 05-278r2: [139:23] 7.4.1.3, third paragraph ("If is an allocated..."), - replace "or" by a comma; - after "differ" insert ", or if the dynamic type of and differ". 05-198r1 with 05-278r2: (modified by 06-154r4:) [139:23] 7.4.1.3, third paragraph ("If is an allocated..."), - replace "or" by a comma; - after "differ" insert ", or if the dynamic type of the variable and differ". 05-198r1: [139:25] 7.4.1.3 Interpretation of intrinsic assignments, third paragraph, delete the instance of "and" before "with each lower bound ...". 05-198r1: [139:26] 7.4.1.3 Interpretation of intrinsic assignments, third paragraph, after "LBOUND()" insert ", and with the same dynamic type as ". 05-278r2: (modified by 06-154r4:) [140:1] 7.4.1.3, paragraph following Note 7.35 (the note begins "For example, given the declaration ...") replace the second occurrence of "" by "the variable". NOTE FROM THE EDITOR: Modified more than what 06-154r4 said. 05-278r2: (modified by 06-154r4:) [140:2-3] 7.4.1.3, first paragraph after Note 7.36 (the note begins "For example, in the character intrinsic ...") replace both occurrences of "" by "the variable". 05-278r2: (modified by 06-154r4:) [140:4-5] 7.4.1.3, second paragraph after Note 7.36, replace both occurrences of "" by "the variable". 05-278r2: (modified by 06-154r4:) [141:1-3] 7.4.1.3, first paragraph after Note 7.38, (the note begins "For example, the following program ...") replace both occurrences of "" by "the variable". 05-278r2: (modified by 06-154r4:) [141:3+2-5] 7.4.1.3, Table 7.9 Numeric conversion and the assignment statement, In the heading replace "" by "the variable". NOTE FROM THE EDITOR: DELETED THE SECOND PART OF THIS EDIT (06-154r4 should have said to do that.) 05-278r2: (modified by 06-154r4:) [141:4-5] 7.4.1.3, first paragraph after Table 7.9, replace both occurrences of "" by "the variable". 05-278r2: (modified by 06-154r4:) [141:6-11] 7.4.1.3, second paragraph after Table 7.9, replace "" by "the variable" all 6 times. 05-278r2: (modified by 06-154r4:) [141:12-13] 7.4.1.3, third paragraph after Table 7.9, [141:12-13] Replace the first two occurrences of "" by "the variable". NOTE FROM THE EDITOR: DELETED THE SECOND PART OF THIS EDIT (06-154r4 should have said to do that.) 06-175r2: (modified by the spirit of 06-154r4:) [141:14-] 7.4.1.3 Interpretation of intrinsic assignments, immediately after Note 7.39 (before "A derived-type intrinsic assignment is performed ..."), insert "For a bits intrinsic assignment statement, the variable and may have different types or different kind type parameters, in which case the value of is converted to the type and kind type parameter of the variable according to the rules of Table 7.9a. Table 7.9a: Bits conversion and the assignment statement Type of variable Value Assigned integer INT (, KIND = KIND()) real REAL (, KIND = KIND()) complex CMPLX (, KIND = KIND()) logical LOGICAL (, KIND = KIND()) bits BITS (, KIND = KIND()) Note: The functions BITS, INT, LOGICAL, REAL, CMPLX, and KIND are the generic functions defined in 13.7." NOTE FROM THE EDITOR: Reordered to be the same as the order elsewhere. "Note 7.39a Bits assignment is not always the same as the result of the TRANSFER intrinsic, because: (a) bits assignment operates elementally, whereas TRANSFER does not preserve array element boundaries; (b) for scalars, if the source is larger TRANSFER uses those bits which occur first in memory whereas bits assignment always uses the "rightmost" bits (according to the model for bits values), independent of the endianness of the processor's memory addressing; (c) if the source is smaller, TRANSFER copies it to the part of the result which occurs first in memory address order and leaves the remaining bits of the result processor-dependent, whereas bits assignment copies the source to the rightmost bits and makes the remaining bits all zero. [end Note]". 05-278r2: (modified by 06-154r4:) [141:14-23] 7.4.1.3, first paragraph after Note 7.39 and its numbered list, (the note begins "For nondefault character types ..." Replace "" by "the variable" all 4 times. 06-174r3: [141:17] 7.4.1.3, same paragraph, before "and intrinsic assignment" insert "intrinsic assignment for each co-array component,". [141:18] Before "allocatable component", Change "For an" to "For a non-co-array". COMMENT FROM THE EDITOR: Reworded. 05-278r2: (modified by 06-154r4:) [142:0+6] 7.4.1.3, Note 7.41 (begins "If an allocatable ...) replace "" by "the variable". 05-278r2: (modified by 06-154r4:) [142:1-2] 7.4.1.3, last paragraph (immediately after Note 7.41) replace both occurrences of "" by "the variable". 06-176 (subgroup beta): [142:1-3] 7.4.1.3, last paragraph "When is a subobject ...", Delete whole paragraph. NOTE FROM THE EDITOR: The subgroup beta of 06-176 actually proposed (an unnecessary) repair to this paragraph, but it has come to my attention that the paragraph is both (a) unnecessary (b) redundant (c) incorrect because: (a) assignment to a variable that is a subobject also does not make a cup of coffee for the editor, but we do not say that; (b) we already say what the effect of assignment *is*, we do not need to say what the effect of assignment "is not"; (c) assignment can too affect the definition status of other parts of an object: auto-reallocation of any allocatable components can cause a pointer component to have its association status become "undefined", and therefore have its definition status go undefined. Therefore I have made the editorial decision to delete the paragraph instead. 05-278r2: (modified by 06-154r4:) [142:27-30] 7.4.1.5 Interpretation of defined assignment statements, second paragraph, replace all 3 occurrences of "" by "the variable". 06-143: [142:28] 7.4.1.5, second paragraph, first sentence, Delete ", in any order,". 06-143: [143:1-] 7.4.1.5, at the end in the last note (7.42), Append a sentence to the note "If an elemental assignment is defined by a pure elemental subroutine, the element assignments may be performed simultaneously or in any order.". 06-175r2: [143:14] 7.4.2 Pointer assignment, first constraint (C716) after BNF R736 , after "and the corresponding kind type parameters shall be equal", insert ", or and shall be bits compatible (5.1.1.2).". 05-273r3: [143:21] 7.4.2, Pointer assignment, in C720 After "If " change "is specified, ... otherwise" to "is not specified," no paper: [143:23+] 7.4.2, After the penultimate constraint (C721) before BNF R737 , insert new constraint "C721a (R736) A shall be a ." COMMENT FROM THE EDITOR: Integration of the change of to include pointer function references. 06-174r3: [143:25+] 7.4.2, after the last constraint before BNF R737 , insert new constraint "C722a (R735) A shall not be a co-indexed object." NOTE FROM THE EDITOR: New edit suggested by subgroup. 06-174r3: [143:31+] 7.4.2, after the first constraint (C723) after R739 , insert new constraint and note "C723a (R739) A shall not be a co-indexed object. NOTE 7.42a A data pointer and its target are always on the same image. A co-array may be of a derived type with pointer or allocatable subcomponents. For example, if PTR is a pointer component, Z[P]%PTR is a reference to the target of component PTR of Z on image P. This target is on image P and its association with Z[P]%PTR must have been established by the execution of an allocate statement or a pointer assignment on image P. [end NOTE]". 05-202r1: [144:5] 7.4.2, penultimate constraint (C727) After "external" insert ", internal", Making the constraint read: "C727 (R742) A shall be the name of an external, internal, module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet (O), or a procedure pointer." 06-175r2: [144:21] 7.4.2.1 Data pointer assignment, fourth paragraph, first sentence, after "as the corresponding type parameters of " insert ", or and shall be bits compatible (5.1.1.2).". 05-273r3: [144:25+] 7.4.2.1 Data pointer assignment, after the fifth paragraph which reads "If has nondeferred ..." Add new paragraph "If has the CONTIGUOUS attribute, shall be contiguous." 05-273r3: [144:26] 7.4.2.1, penultimate paragraph, before "shall not be a disassociated", insert "shall be contiguous ([xref to the definition of contiguous]) or of rank one. It" 05-202r1: [144:38+] 7.4.2.2 Procedure pointer assignment, after the first paragraph (which ends with "associated with the same procedure."), Insert a new paragraph "If is the name of an internal procedure the <> of becomes the innermost currently executing instance of the host procedure. Otherwise if has a host instance the host instance of becomes that instance. Otherwise has no host instance." 05-273r3: [145:9+19] 7.4.2.3 Examples, last note (Note 7.44), first sentence, Change "high-rank views of (parts of) rank-one objects" to "different-rank views of parts of an object" [145:9+20] 7.4.2.3, last note in subclause (Note 7.44), after first sentence, Insert new sentence "This requires that the object be either rank one or contiguous." Missing from 05-278r2: (modified by 06-154r4:) [146:30] 7.4.3 Masked array assignment - WHERE, last normative paragraph (before Note 7.45), last sentence Replace "the being defined" By "the variable being defined". 05-278r2: (modified by the editor in the spirit of 06-154r4:) [147:19, 23] 7.4.3.2 Interpretation of masked array assignments, third paragraph after Note 7.46 (paragraph begins "If a nonelemental function reference ..."), NOTE FROM THE EDITOR: DELETED THIS EDIT (not what 06-154r4 said to do to it), BECAUSE IT IS NO LONGER NEEDED. 05-278r2: (modified by 06-154r4:) [147:24] 7.4.3.2, fourth paragraph after Note 7.46, Replace the second occurrence of "" by "assigned variable,". NOTE FROM THE EDITOR: DELETED THE FIRST PART OF THIS EDIT, BECAUSE IT IS NO LONGER NEEDED. 05-278r2: (modified by 06-154r4:) [148:5] 7.4.3.2, near the end, paragraph beginning "When a ..." Replace "" by "the variable". 05-278r2: (modified by the editor in the spirit of 06-154r4:) [149:12+] 7.4.4.1 The FORALL construct, immediately after the last constraint C739, insert new constraint "C739a (R757) The in an that is a shall be a .". NOTE FROM THE EDITOR: CHANGED THIS EDIT (missed by 06-154r4). 06-174r3: [155:2-3] 8 Execution control, first paragraph, delete. NOTE FROM THE EDITOR: This seems preferable to the edit to "fix up" the non-ISO-compliant waffle. NOTE FROM THE EDITOR: If image synchronisation does not fall under the broad topic of "Execution control", the title should be changed. Anyway, we certainly do not need this padding. 06-142: [155:6+] 8.1 Executable constructs containing blocks, first paragraph, numbered list, insert new list item in alphabetic order "(1a) BLOCK construct". 06-174r3: [155:7+] 8.1, first paragraph, numbered list, insert new list item in alphabetic order "(2a) CRITICAL construct". 05-273r3: [161:19] 8.1.4.3 Attributes of associate names, Before "TARGET, or VOLATILE" insert "CONTIGUOUS,". 05-237r4: [164:3] 8.1.6 DO construct, first paragraph, second sentence, replace "The EXIT and CYCLE statements" with: "The EXIT statement, except in a DO CONCURRENT construct, and the CYCLE statement" 05-237r4: [164:6] 8.1.6 DO construct, second paragraph, second sentence, replace "In either case," with: "Except in the case of a DO CONCURRENT construct," 05-237r4: [164:8+] 8.1.6 DO construct, after the second paragraph, insert new paragraph: "A <> construct is a DO construct with a of [,] CONCURRENT ." 05-237r4: [165:15+] 8.1.6.1.1, Form of the block DO construct, R830 , add a new line at the end of R830 "<> [,] CONCURRENT " 06-154r4: [165:16] 8.1.6.1.1, R831 , replace "" with "". 06-154r4: [165:17] 8.1.6.1.1, first constraint (C820) after R831 , delete "named scalar". 05-237r4: [167:7+] 8.1.6.4.1 Loop initiation, before the last paragraph insert new paragraphs: "For a DO CONCURRENT construct, the values of the index variables for the iterations of the construct are determined by the rules for the index variables of the FORALL construct (7.4.4.2.1 and 7.4.4.2.2). The number of distinct index value combinations in the active combination of values is the iteration count for the construct. An in a DO CONCURRENT construct has a scope of the construct (16.3). It is a scalar variable that has the type and type parameters that it would have if it were the name of a variable in the scoping unit that includes the DO CONCURRENT, and this type shall be integer type; it has no other attributes." 05-237r4: [167:10] 8.1.6.4.2 The execution cycle, first sentence, replace "The <> of a DO construct consists of" with: "The <> of a DO construct that is not a DO CONCURRENT construct consists of" 05-237r4: [167:23+] 8.1.6.4.2 The execution cycle, append a new paragraph: "The range of a DO CONCURRENT construct is executed for all of the active combinations of the values. Each execution of the range is an <>. The executions may occur in any order." 05-237r4: [167:25] 8.1.6.4.3 CYCLE statement, first sentence, replace "Step (2) in the above execution cycle may be curtailed" with: "Execution of the range of the loop may be curtailed" 05-237r4: [167:29+] 8.1.6.4.3 CYCLE statement, after constraint C828, add a new constraint: "C828a (R843) A shall not appear within the range of a DO CONCURRENT construct if it belongs to a construct that contains the DO CONCURRENT construct." 05-237r4: [167:33] 8.1.6.4.3 CYCLE statement, penultimate paragraph, beginning of the first sentence, replace "Execution of a CYCLE statement causes" with: "Execution of a CYCLE statement that belongs to a DO construct that is not a DO CONCURRENT construct causes" 05-237r4: [167:34] 8.1.6.4.3 CYCLE statement, penultimate paragraph, after the first sentence, add a new sentence: "Execution of a CYCLE statement that belongs to a DO CONCURRENT construct curtails that iteration of the construct." 05-205r2: [168:4-10] 8.1.6.4.4 Loop termination, Delete the first two paragraphs and the syntax rules for EXIT. NOTE: CONFLICT with following edit. If doing both, this takes precedence. 05-237r4: [168:7+] 8.1.6.4.4 Loop termination, after constraint C829, add a new constraint "C829a (R844) An shall not belong to a DO CONCURRENT construct, nor shall it appear within the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO CONCURRENT construct." NOTE: CONFLICT with preceding edit. If doing both, this gets omitted. 05-205r2: [168:11] 8.1.6.4.4 Loop termination, third textual paragraph, Change "The loop" to "A loop". NOTE: EDIT OVERLAP - edit from 05-237r4 takes precedence. 05-237r4: [168:11] 8.1.6.4.4 Loop termination, beginning of the sentence before the list of items, replace "The loop terminates" with: "For a DO construct that is not a DO CONCURRENT construct, the loop terminates" NOTE TO EDITOR: EDIT OVERLAP. 05-205r2: [168:16] 8.1.6.4.4 Loop termination, numbered list, item (3), change "outer DO construct" to "outer construct". 05-237r4: [168:23+] 8.1.6.4.4 Loop termination, append new paragraph: "For a DO CONCURRENT construct, the loop terminates, and the DO construct becomes inactive when all of the iterations have completed execution." 05-237r4: [168:24-] Between subclauses "8.1.6.4.4 Loop termination" and "8.1.6.5 Examples of DO constructs", insert a new subsection (containing 2 notes): "8.1.6.4a Restrictions on DO CONCURRENT constructs A statement in the loop range shall not cause a branch out of the construct. A variable that is referenced in an iteration shall either be previously defined during that iteration, or shall be defined or become undefined during any other iteration of the current execution of the construct. A variable that is defined or becomes undefined by more than one iteration of the current execution of the construct becomes undefined when the current execution of the construct terminates. A pointer that is referenced in an iteration either shall be previously pointer associated during that iteration, or shall not have its pointer association changed during any iteration. A pointer that has its pointer association changed in more than one iteration has a processor dependent association status when the construct terminates. An allocatable object that is allocated in more than one iteration shall be subsequently deallocated during the same iteration in which it was allocated. An object that is allocated or deallocated in only one iteration shall not be deallocated, allocated, referenced, defined, or become undefined in a different iteration. An input/output statement shall not write data to a file record or position in one iteration and read from the same record or position in a different iteration of the same execution of the construct. Records written by output statements in the loop range to a sequential access file appear in the file in an indeterminate order. Procedures referenced in the loop range shall be PURE. If the IEEE_EXCEPTIONS intrinsic module is accessible, calls to the IEEE_GET_FLAG, IEEE_SET_HALTING_MODE, and IEEE_GET_HALTING_MODE subroutines shall not appear in the loop range. Note 8.15a The restrictions on referencing variables defined in an iteration of a DO CONCURRENT construct apply to any procedure invoked within the loop. [end Note] Note 8.15b The restrictions on the statements in the loop range of a DO CONCURRENT construct are designed to ensure there are no data dependencies between iterations of the loop. This permits code optimizations that might otherwise be difficult or impossible because they would depend on characteristics of the program not visible to the compiler. [end Note]" 05-237r4: [169:1--] 8.1.6.5 Examples of DO constructs, after Note 8.18, add a new note: "Note 8.18a The following example represents a case in which the user knows that the elements of the array IND form a permutation of the integers 1..N. The DO CONCURRENT construct will allow the compiler to generate vector gather/scatter code, unroll the loop, or parallelize the code for this loop, significantly improving performance. INTEGER :: A(N,N),IND(N) DO CONCURRENT (I=1:N, J=1:N) A(IND(I),IND(J)) = A(IND(I),IND(J)) + 1 END DO" 05-205r2 with 05-237r4: [169:1-] Immediately before 8.2 Branching, insert new subclause "8.1.7 EXIT statement The EXIT statement provides one way of terminating a construct. R844 <> EXIT [ ] C829 (R844) If an refers to a , it shall be within that construct; otherwise, it shall be within the range of at least one . An EXIT statement belongs to a particular construct. If the EXIT statement refers to a construct name, it belongs to that construct; otherwise, it belongs to the innermost DO construct in which it appears. C829a (R844) An shall not belong to a DO CONCURRENT construct, nor shall it appear within the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO CONCURRENT construct. When an EXIT statement that belongs to a DO construct is executed, it terminates the loop (8.1.6.4.4) and any active loops contained within the terminated loop. When an EXIT statement that belongs to a non-DO construct is executed, it terminates any active loops contained within that construct, and completes execution of that construct." NOTES: (1) To do this without 05-237r4, omit constraint C829a. (2) I deliberately put the constraint after the definition of the term it uses, instead of immediately after C829. 06-142: [169:1-] Immediately before 8.2 Branching, but after the edit from 05-205r2, insert new subclause "8.1.7 BLOCK construct The BLOCK construct is a block which may contain declarations. R8m1 <> [ ] R8m2 <> [ : ] BLOCK R8m3 <> END BLOCK [ ] C8m1 (R8m1) If the of a specifies a , the corresponding shall specify the same . If the does not specify a , the corresponding shall not specify a . Specifications in a BLOCK construct declare construct entities whose scope is that of the BLOCK construct. Specification expressions in the are evaluated when the BLOCK statement is executed. The BLOCK construct terminates when a RETURN statement within the block is executed, or when transfer of control to a statement outside the block occurs." 06-175r3: [169:1-] Immediately before 8.2 Branching, but after the edit from 06-142, insert new subclause "8.1.8 CRITICAL construct A <> limits execution of a block to one image at a time. R844a <> R844b <> [:] CRITICAL R844c <> END CRITICAL [] C829a (R844a) If the of a specifies a , the corresponding shall specify the same . If the of a does not specify a , the corresponding shall not specify a . C829b (R844a) The of a shall not contain an image control statement." NOTE TO EDITOR: Changes to the definition of "transferred" might involve a change to the following paragraph. NOTE FROM THE EDITOR: Huh? "A critical construct completes execution if the END CRITICAL statement is executed or if control is transferred to a branch target outside the block. The processor shall ensure that once an image has commenced executing , no other image shall commence executing it until the image has completed executing it. If image T is the next to execute the construct after image M, the segments (8.5.1) that executed before the construct on image M precede the segments that execute after the construct on image T. No image control statement shall be executed during the execution of a critical construct by the image executing the critical construct. NOTE 8.19a If more than one image executes the block of a critical construct, its execution by one image always either precedes or succeeds its execution by another image. Typically no other statement ordering is needed. Consider the following example: CRITICAL global_counter[1] = global_counter[1] + 1 END CRITICAL The definition of global_counter[1] by a particular image will always precede the reference to the same variable by the next image to execute the block. [end NOTE] NOTE 8.19b The following example permits a large number of jobs to be shared among the images: INTEGER :: NUM_JOBS[*], JOB IF (THIS_IMAGE() == 1) READ(*,*) NUM_JOBS SYNC_ALL DO CRITICAL JOB = NUM_JOBS[1] NUM_JOBS[1] = JOB - 1 END CRITICAL IF (JOB > 0) THEN ! Work on JOB ELSE EXIT END IF END DO SYNC_ALL [end NOTE]". NOTE FROM THE EDITOR: I STILL DISLIKE PUTTING THIS IN THE MIDDLE OF THE NORMAL EXECUTION CONTROL STUFF. NOTHING IT SAYS MAKES ANY SENSE WITHOUT THE DEFINITION OF SEGMENT ETC IN THE SYNCHRONISATION SUBCLAUSE. IT BELONGS ***THERE***. 05-231r4: [170:22-24] 8.4 STOP Statement, Replace R850 and C834 with: "R850 <> <> C834 (R850) The shall be of default kind. C834a (R850) The shall be of default kind." [170:25-26] 8.4, first textual paragraph, first sentence, Replace the first sentence with the following, making the rest of the first paragraph into a separate (now third) paragraph: "Normal termination of execution of the program occurs on all images if a STOP statement or is executed immediately after a SYNC_ALL (8.5.2) statement on all images. J3 TECHNICAL NOTE (0) As I said before, normal termination of the *program* inherently is all images. J3 TECHNICAL NOTE This is ambiguous on several levels. Does it mean a particular SYNC_ALL statement on all images? ...Or the usual "any SYNC_ALL statement" syncs with any other? Does it mean that a STOP or is executed on all images? ...Or can one image decide unilaterally to normally terminate the program? From the alternative (STOP statement that does not immediately follow a SYNC_ALL statement) it seems that unilateralism might be what is intended, except that then not all cases seem to be covered in the "how many images execute a STOP" situation... [the next sentence is supposed to be in the same paragraph] The stop code, if any, and warnings of any exceptions that are signaling shall be made available only for image 1. J3 TECHNICAL NOTE (1) "made available etc." not meaningful. (I might have mentioned this before...) J3 TECHNICAL NOTE (2) This is not the place for redundant specification of what END PROGRAM does. If we want to centralise termination, fine, but centralise it don't duplicate it. The processor shall ensure that once an image has commenced executing a STOP or an statement that does not immediately follow a SYNC_ALL statement, no other image shall commence executing such a statement. It causes normal termination (2.3.4) of execution of the program on that image. The stop code, if any, and warnings of any exceptions that are signaling shall be made available only for that image. The executions of all other images are terminated. J3 TECHNICAL NOTE What does this mean? The other image hangs forever? The other image is terminated immediately? How can you tell it doesn't execute a STOP (since presumably it terminates somehow anyway...). Why does this only apply to STOP not preceded by SYNC_ALL?". NOTE FROM THE EDITOR: HERE IS A POSSIBLE REWRITE, BASED ON MY GUESSES AS TO HOW TO RESOLVE THE TECHNICAL NOTES ABOVE. "Execution of a STOP statement causes normal termination of that image and termination of the program. If there is only one image, or the STOP statement is executed immediately after a SYNC_ALL (8.5.2) statement, the program is terminated normally (2.3.4). If several images execute a STOP statement or , it is processor-dependent which image's stop code or signalling exception warning is made available, except that if a STOP statement is executed immediately after a SYNC_ALL statement on image 1, the stop code and signaling exceptions on image 1 are reported." NOTE: REWRITE REJECTED BY SUBGROUP. 06-174r3: In any case, somewhere in STOP insert "J3 TECHNICAL NOTE Why is image 1 special? What if every other image terminates first, before image 1 does? J3 TECHNICAL NOTE If some image registers an "atexit" procedure, normal termination of execution is required to invoke it. Does this invocation occur on the registering image or on image 1 or ??? I'm just confused on this one, it might not be a real problem. J3 TECHNICAL NOTE Exception warnings appear to be only required in F2003 for STOP, not for . Assuming that was a deliberate decision, changing this requirement for co-arrays seems outwith the scope of the feature. Not that it might not be a good idea, but it just does not seem to have anything to do with co-arrays as such.". 05-231r4: [170:26-27] 8.4 STOP Statement, First textual paragraph, delete the third sentence which reads "Leading zero digits ... are not significant." 05-231r4: [170:29+] 8.4 STOP statement, end of subclause, append new paragraph and note: "It is recommended that the is made available by formatted output to the processor-dependent external unit identified by the named constant ERROR_UNIT of the ISO_FORTRAN_ENV intrinsic module (Section 9.4). Note 8.21+ If the is an integer, it is recommended that the value also be used as the process exit status, if the operating system supports that concept. If the integer is used as the process exit status, the operating system might be able to interpret only values within a limited range, or only a limited portion of the integer value (for example, only the least-significant 8 bits)." 06-175r4: [170:29+] At the end of clause 8, add a new subclause "8.5 Image execution control 8.5.1 Image control statements The execution sequence on each image is as specified in 2.3.4. An <> statement affects the execution ordering between images. Each of the following is an image control statement: (1) SYNC_ALL statement, (2) SYNC_TEAM statement, (3) SYNC_IMAGES statement, (4) SYNC_MEMORY statement, (5) NOTIFY statement, (6) QUERY statement, (7) ALLOCATE or DEALLOCATE statement involving a co-array, (8) CRITICAL or END CRITICAL statement (8.1.8), (9) OPEN statement with a TEAM= specifier, (10) CLOSE statement for a file that is open with a TEAM= specifier, (11) END, END BLOCK, or RETURN statement that involves an implicit deallocation of a co-array, and (12) CALL statement for a collective subroutine (13.1). On each image, the sequence of statements executed before the first image control statement, between the execution of two image control statements, or after the last image control statement is known as a <>. The segment executed immediately before the execution of an image control statement includes the evaluation of all expressions within the statement. By execution of image control statements or user-defined ordering (8.5.6), the program can ensure that the execution of the i-th segment on image P, S(i,P), either precedes or succeeds the execution of the j-th segment on another image Q, S(j,Q). If the program does not ensure this, segments S(i,P) and S(j,Q) are <>; depending on the relative execution speeds of the images, some or all of the execution of the segment S(i,P) may take place at the same time as some or all of the execution of the segment S(j,Q). NOTE 8.22 The set of all segments on all images is partially ordered: the segment S(i,P) precedes segment S(j,Q) if and only if there is a sequence of segments starting with S(i,P) and ending with S(j,Q) such that each segment of the sequence precedes the next either because they are on the same image or because of the execution of image control statements or user-defined ordering. [end NOTE] A scalar co-variable that is of type default integer, default logical, default real, or default bits, and has the VOLATILE attribute (5.1.2.16) may be referenced during the execution of a segment that is unordered relative to the execution of a segment in which the co-variable is defined. Otherwise, (1) if a co-array variable is defined on an image in a segment, it shall not be referenced or defined in a segment on another image unless the segments are ordered, (2) if the allocation of an allocatable subobject of a co-array or the association of a pointer subobject of a co-array is changed on an image in a segment, that subobject shall not be referenced or defined in a segment on another image unless the segments are ordered, and (3) if a procedure invocation on image P is in execution in segments S(i,P), S(i+1,P), ..., S(k,P) and defines a non-co-array dummy argument, the corresponding actual argument shall not be referenced or defined on another image Q in a segment S(j,Q) unless S(j,Q) precedes S(i,P) or succeeds S(k,P). NOTE 8.22a Apart from the effects of volatile variables, the processor may optimize the execution of a segment as if it were the only image in execution. [end NOTE] NOTE 8.22b The model upon which the interpretation of a program is based is that there is a permanent memory location for each co-array variable and that all images can access it. In practice, an image may make a copy of a non-volatile co-array variable (in cache or a register, for example) and, as an optimization, defer copying a changed value back to the permanent location while it is still being used. Since the variable is not volatile, it is safe to defer this transfer until the end of the current segment and thereafter to reload from permanent memory any co-array variable that was not defined within the segment. It would not be safe to defer these actions beyond the end of the current segment since another image might reference the variable then. [end NOTE] If an image P writes a record during the execution of segment S(i,P) to a file that is opened for direct access with a TEAM= specifier, no other image Q shall read or write the record during execution of a segment that is unordered with S(i,P). Furthermore, it shall not read the record in a segment that succeeds S(i,P) unless (1) after image P writes the record, it executes a FLUSH statement (9.8) for the file during the execution of a segment S(k,P), and (2) before image Q reads the record, it executes a FLUSH statement for the file during the execution of a segment S(j,Q) that succeeds S(k,P). 8.5.2 SYNC_ALL statement R851 <> SYNC_ALL [([])] R852 <> STAT = <> ERRMSG = C835 (R851) No specifier shall appear more than once in a given ." NOTE FROM THE EDITOR: Deleted C836 after consultation with subgroup. "The STAT= and ERRMSG= specifiers are described in 8.5.7. Execution of a SYNC_ALL statement performs a synchronization of all images. Execution on an image, M, of the segment following the SYNC_ALL statement is delayed until each other image has executed a SYNC_ALL statement as many times as has image M. The segments that executed before the SYNC_ALL statement on an image precede the segments that execute after the SYNC_ALL statement on another image. NOTE 8.23 The processor might have special hardware or employ an optimized algorithm to make the SYNC_ALL statement execute efficiently. Here is a simple example of its use. Image 1 reads data and broadcasts it to other images: REAL :: P[*] ... SYNC_ALL IF (THIS_IMAGE()==1) THEN READ (*,*) P DO I = 2, NUM_IMAGES() P[I] = P END DO END IF SYNC_ALL [end NOTE] NOTE 8.23a If synchronization is required when the images commence statement execution, a SYNC_ALL statement should be the first executable statement of the main program. This is necessary if the code relies on the initialization of a co-array variable on another image. [end NOTE] 8.5.3 SYNC_TEAM statement R853 <> SYNC_TEAM ( [,]) R854 <> C837 (R853) No specifier shall appear more than once in a given . C838 (R854) shall be a scalar variable of the type IMAGE_TEAM defined in the intrinsic module ISO_FORTRAN_ENV. Execution of a SYNC_TEAM statement performs a <>, which is a synchronization of the images in a team. The team is specified by the value of and shall include the executing image. All images of the team shall execute a SYNC_TEAM statement with a value of that was constructed by invoking FORM_TEAM for the team. They do not commence executing subsequent statements until all images in the team have executed a SYNC_TEAM statement for the team an equal number of times since FORM_TEAM was invoked for the team. If images M and T are any two members of the team, the segments that execute before the statement on image M precede the segments that execute after the statement on image T. Team synchronization is also performed by an OPEN statement with a TEAM= specifier, a CLOSE statement for a file that is open with a TEAM= specifier, or the invocation of a collective subroutine. NOTE 8.24 Here is an example where the images are divided into two teams, one for an ocean calculation and one for an atmosphere calculation. USE, INTRINSIC :: ISO_FORTRAN_ENV TYPE(IMAGE_TEAM) :: TEAM INTEGER :: N2, STEP, NSTEPS LOGICAL :: OCEAN N2 = NUM_IMAGES()/2 OCEAN = (THIS_IMAGE()<=N2) IF(OCEAN) THEN CALL FORM_TEAM(TEAM, (/ (I, I=1,N2) /) ) ELSE CALL FORM_TEAM(TEAM, (/ (I, I=N2+1,NUM_IMAGES()) /) ) END IF : ! Initial calculation SYNC_ALL DO STEP = 1, NSTEPS IF (OCEAN) THEN DO : ! Ocean calculation SYNC_TEAM(TEAM) IF ( ... ) EXIT ! Ready to swap data END DO ELSE DO : ! Atmosphere calculation SYNC_TEAM(TEAM) IF ( ... ) EXIT ! Ready to swap data END DO END IF SYNC_ALL : ! Swap data END DO In the inner loops, each set of images first works entirely with its own data and each image synchronizes with the rest of its team. The number of synchronizations for the ocean team might differ from the number for the atmosphere team. The SYNC_ALL statement that follows is needed to ensure that both teams have done their calculations before data are swapped. [end NOTE] 8.5.4 SYNC_IMAGES statement R855 <> SYNC_IMAGES ( [,]) R856 <> <> * C839 (R855) No specifier shall appear more than once in a given . C840 (R856) An that is an shall be scalar or of rank one and shall not contain an (6.2a). If is an array expression, the value of each element shall be in the range 1, ..., NUM_IMAGES(), and there shall be no repeated values. If is a scalar expression, its value shall be in the range 1, ..., NUM_IMAGES(). An that is an asterisk specifies all images. Execution of a SYNC_IMAGES statement performs a synchronization of the image with each of the other images in the . Execution on an image, M, of the segment following the SYNC_IMAGES statement is delayed until all other images T in the have executed a SYNC_IMAGES statement with M in its as many times as image M has executed a SYNC_IMAGES statement with T in the . The segments that executed before the SYNC_IMAGES statement on image M precede the segments that execute after the SYNC_IMAGES statement on image T. NOTE 8.25 A SYNC_IMAGES statement that specifies the single image value THIS_IMAGE() in its image set is allowed. This simplifies writing programs for an arbitrary number of images by allowing correct execution in the limiting case of the number of images being equal to one. [end NOTE] NOTE 8.25a Execution of a SYNC_IMAGES(*) statement is not equivalent to the execution of a SYNC_ALL statement. SYNC_ALL causes all images to wait for each other. SYNC_IMAGES statements are not required to specify the same image set on all the images participating in the synchronization. In the following example, image 1 will wait for each of the other images to complete its use of the data. The other images wait for image 1 to set up the data, but do not wait on any of the other images. IF (THIS_IMAGE() == 1) then ! Set up co-array data needed by all other images SYNC_IMAGES(*) ELSE SYNC_IMAGES(1) ! Use the data set up by image 1 END IF [end NOTE] NOTE 8.25b Execution of a SYNC_TEAM statement causes all the images of the team to wait for each other. There might, however, be situations where this is not efficient. In the following example, each image synchronizes with its neighbor. INTEGER :: ME, NE, STEP, NSTEPS NE = NUM_IMAGES() ME = THIS_IMAGE() ! Initial calculation SYNC_ALL DO STEP = 1, NSTEPS IF (ME > 1) SYNC_IMAGES(ME-1) ! Perform calculation IF (ME < NE) SYNC_IMAGES(ME+1) END DO SYNC_ALL The calculation starts on image 1 since all the others will be waiting on SYNC_IMAGES(ME-1). When this is done, image 2 can start and image 1 can perform its second calculation. This continues until they are all executing different steps at the same time. Eventually, image 1 will finish and then the others will finish one by one. The SYNC_IMAGES syntax involves rather than to allow the set of images to vary from image to image. [end NOTE] 8.5.5 NOTIFY and QUERY statements R857 <> NOTIFY ( [,]) R858 <> QUERY ( [,]) R859 <> READY = <> C841 (R857) No specifier shall appear more than once in a given . C842 (R858) No specifier shall appear more than once in a given . Execution on image M of a NOTIFY statement with a different image T in its increments by 1 a record of the number of times, n(M,T), image M executed such a NOTIFY statement. The execution of a QUERY statement on an image is called <> if the QUERY statement has no READY= specifier or if it has a READY= specifier whose value after the statement has been executed is true. Execution on image M of a blocking QUERY statement with a different image T included in its image set increases by 1 a record of the number of times, b(M,T), image M executed such a QUERY statement. This increase is made after its value has been compared with n(T,M). If a READY= specifier appears, execution on image M of a QUERY statement causes the to become defined. The value is false if, for a different image T in the image set, n(T,M) <= b(M,T). Otherwise, the value is true. If a READY= specifier does not appear, increasing b(M,T) and completing execution of the statement is delayed until, for each different T in the image set, n(T,M) > b(M,T). For a blocking QUERY statement on image M with a different image T in its image set, the NOTIFY statement execution on image T for which n(T,M) = b(M,T) + 1 is said to correspond to it. Segments on image T executed before the execution of this NOTIFY statement precede the executions of the segments on image M that follow this QUERY statement. NOTE 8.26 The NOTIFY and QUERY statements can be used to order statement executions between a producer and consumer image. INTEGER,PARAMETER :: PRODUCER = 1, CONSUMER = 2 INTEGER :: VALUE[*] LOGICAL :: READY SELECT CASE (THIS_IMAGE()) CASE(PRODUCER) VALUE[CONSUMER] = 3 NOTIFY(CONSUMER) CASE(CONSUMER) WaitLoop: DO QUERY(PRODUCER,READY=READY) IF(READY) EXIT WaitLoop ! Statements not referencing VALUE[CONSUMER], or causing it to ! become defined or undefined END DO WaitLoop ! references to VALUE CASE DEFAULT ! Statements not referencing VALUE[CONSUMER], or causing it to ! become defined or undefined END SELECT Unlike SYNC_IMAGES statements, the number of notifications and corresponding blocking queries may be unequal. A program can complete with an excess number of notifies. [end NOTE] NOTE 8.27 NOTIFY/QUERY pairs can be used in place of SYNC_ALL and SYNC_IMAGES to achieve better load balancing and allow one image to proceed with calculations while another image is catching up. Here is an example: IF (THIS_IMAGE()==1) THEN DO I=1,100 ! Primary processing of column I NOTIFY(2) ! Done with column I END DO SYNC_IMAGES(2) ELSE IF (THIS_IMAGE()==2) THEN DO I=1,100 QUERY(1) ! Wait until image 1 is done with column I ! Secondary processing of column I END DO SYNC_IMAGES(1) END IF [end NOTE] NOTE 8.28 The incorrect sequencing of image control statements can halt execution indefinitely. For example, one image might be executing a SYNC_ALL statement while another is executing an ALLOCATE statement for a co-array; or one image might be executing a blocking QUERY statement for which an image in its image set never executes the corresponding NOTIFY statement. [end NOTE] 8.5.6 SYNC_MEMORY statement The SYNC_MEMORY statement provides a means of dividing a segment on an image into two segments, each of which can be ordered in some user-defined way with respect to segments on other images. R860 <> SYNC_MEMORY [([])] C843 (R860) No specifier shall appear more than once in a given . NOTE 8.29 SYNC_MEMORY usually suppresses compiler optimizations that might reorder memory operations across the segment boundary defined by the SYNC_MEMORY statement and ensures that all memory operations initiated in the preceding segments in its image complete before any memory operations in the subsequent segment in its image are initiated. It needs to do this unless it can establish that failure to do so could not alter processing on another image. All of the other image control statements include the effect of executing a SYNC_MEMORY statement. In addition, the other image control statements cause some form of cooperation with other images for the purpose of ordering execution between images. SYNC_MEMORY in combination with user-written code that forces synchronization between images can provide an effective and flexible alternative to the image control statements discussed in 8.5.2-8.5.5. A common example of user-written code that can be used in conjunction with SYNC_MEMORY to implement specialized schemes for segment ordering is the spin-wait loop. For example: LOGICAL,VOLATILE :: LOCKED[*] = .TRUE. INTEGER :: IAM, P, Q IAM = THIS_IMAGE() IF (IAM == P) THEN ! Preceding segment SYNC_MEMORY ! A LOCKED[Q] = .FALSE. ! segment S(i,P) SYNC_MEMORY ! B ELSE IF (IAM == Q) THEN DO WHILE (LOCKED); END DO ! segment S(j,Q) SYNC_MEMORY ! C ! Following segment END IF Here, image Q does not complete the segment S(j,Q) until image P executes segment S(i,P). This ensures that executions of segments before S(i,P) on image P precede executions of segments on image Q after S(j,Q). The first SYNC_MEMORY statement (A) ensures that the compiler does not reorder the following statement (locking) with the previous statements, since the lock should be freed only after the work has been completed. The definition of LOCKED[Q] might be deferred to the end of segment S(i,P). The second SYNC_MEMORY statement (B) ends that segment immediately after the definition, minimizing any delay in releasing the lock in segment S(j,Q). The third SYNC_MEMORY statement (C) marks the beginning of a new segment, informing the compiler that the values of co-array variables referenced in that segment might have been changed by other images in preceding segments, so need to be loaded from memory. As a second example, the user might have access to an external procedure that performs synchronization between images. That library procedure will not necessarily be aware of the mechanisms used by the processor to manage remote data references and definitions, and therefore not, by itself, be able to ensure the correct memory state before and after its reference. The SYNC_MEMORY statement provides the needed memory ordering that enables the safe use of the external synchronization routine. For example: INTEGER :: IAM REAL :: X[*] IAM = THIS_IMAGE() IF (IAM == 1) X = 1.0 SYNC_MEMORY CALL EXTERNAL_SYNC() SYNC_MEMORY IF (IAM == 2) WRITE(*,*) X[1] where executing the subroutine EXTERNAL_SYNC has an image synchronization effect similar to executing a SYNC_ALL statement. [end NOTE] 8.5.7 STAT= and ERRMSG= specifiers in image execution control statements If the STAT= specifier appears, successful execution of the SYNC_ALL, SYNC_TEAM, SYNC_IMAGES, SYNC_MEMORY, NOTIFY, or QUERY statement causes the specified variable to become defined with the value zero. If an error occurs during execution of one of these statements, the variable becomes defined with a processor-dependent positive integer value. If an error condition occurs during execution of a SYNC_ALL, SYNC_TEAM, SYNC_IMAGES, SYNC_MEMORY, NOTIFY, or QUERY statement that does not contain the STAT= specifier, the effect is processor dependent. If the ERRMSG= specifier appears and an error condition occurs during execution of the SYNC_ALL, SYNC_TEAM, SYNC_IMAGES, SYNC_MEMORY, NOTIFY, or QUERY statement, the processor shall assign an explanatory message to the specified variable. If no such condition occurs, the processor shall not change the value of the variable. NOTE 8.30 Which errors, if any, are diagnosed is processor dependent. The processor might check that a valid set of images has been provided, with no out-of-range or repeated values. It might test for network time-outs. While the overall program would probably not be able to recover from the failure of an image, it could perhaps provide information on what failed and be able to save some of the program state to a file. [end NOTE]". 06-174r3: [172:26+] 9.2 External files, before the last paragraph, add note "NOTE 9.3a Named files that are opened with the TEAM= specifier (9.4.5.16) have the same name on each image of the team. Apart from this, whether a named file on one image is the same as a file with the same name on another image is processor dependent. For code portability, if different files are needed on each image, different file names should be used. One technique is to incorporate the image number as part of the name. [end NOTE]". 06-174r3: [173:29] 9.2.2.1 Sequential access, numbered list, add new list item "(4) Each record shall be read or written by a single image. The processor shall ensure that once an image commences transferring the data of a record to the file, no other image transfers data to the file until the whole record has been transferred.". 06-138r2: [178:17-18] 9.3 Internal files, numbered list, final item at the end of the subclause, Replace ", a file positioning statement, or a file inquiry statement" With "or a file positioning statement". 06-138r2: [178:30-32] 9.4 File connection, paragraph following the BNF and constraints, Replace " whose value is nonnegative or equal to one of the named constants INPUT_UNIT, OUTPUT_UNIT, or ERROR_UNIT of the ISO_FORTRAN_ENV module (13.8.2). " With ". The value of shall be nonnegative, one of the named constants that identify unit numbers in the ISO_FORTRAN_ENV module (INPUT_UNIT, OUTPUT_UNIT, or ERROR_UNIT) (13.8.2), or a NEWUNIT value (9.4.5.10)." 06-174r3: [178:36] 9.4 File connection, second paragraph, last sentence, append ", and on all images". NOTE FROM THE EDITOR: What entities are shared between images needs to be specified in the "replication" subclause, not have individual bits scattered across the document and buried. 06-174r3: [179:27] 9.4.2 Unit existence, first sentence. After "exist for", add "all the images of". NOTE FROM THE EDITOR: REJECTED. THIS PARAGRAPH IS NOT ABOUT THE SCOPING OF EXTERNAL UNITS. WE ARE *NOT* GOING TO HAVE MULTIPLE SPECIFICATIONS OF A SIMPLE REQUIREMENT - REMEMBER THE DICK WEAVER RULE. 06-174r3: [179:33] 9.4.3 Connection of a file to a unit, second sentence, append ", and the connection is for a team of images". Append to paragraph "J3 TECHNICAL NOTE The second sentence now contradicts the first sentence. Sorry guys, but the unit ***is global*** and only has one state, that of being connected or not. This subclause is about connection, not about whether it is formatted or unformatted, or whether there is some restriction about what image is permitted to reference it. Not doing the edit to the second sentence would be sufficient to resolve this issue.". 06-138r2: [181:33+] 9.4.5 The OPEN statement, BNF R905 , Insert new production in alphabetical order "<> NEWUNIT = ". 06-174r3: [181:39+] 9.4.5, BNF R905 , insert new production alphabetically "<> TEAM = ". NOTE FROM THE EDITOR: I DID THIS WITHOUT A SPURIOUS UNUSED EXTRA BNF TERM. 06-174r3: [181:41+] NOTE FROM THE EDITOR: SPURIOUS UNUSED EXTRA BNF TERM REJECTED. 06-174r3: [185:4+] Immediately before 9.4.6 The CLOSE statement, add new subclause "9.4.5.16 TEAM= specifier in the OPEN statement The specifies the <> for the unit, which is the set of images that are permitted to reference the unit. The team shall include the executing image. If there is no TEAM= specifier, the connect team consists of only the executing image." NOTE FROM THE EDITOR: Improved the wording of the first sentence. "J3 TECHNICAL NOTE There is no INQUIRE(TEAM=) which is rather a glaring omission, since that particular characteristic of a unit is even more important than things like the BLANK= mode, since it determines whether an image is permitted to use the unit. After that is fixed, one might consider allowing INQUIRE to reference a unit even from an image that is not part of the team, at least to find out whether it is connected and what the team is... It was suggested (with edits) that OPENED= should return true only for images in the connect-team. That is completely unacceptable. We cannot seriously think about breaking existing carefully-written libraries and programs that use INQUIRE to discover unused units to use for i/o. That mandates us to have OPENED= return true for any unit that is open, no matter what the TEAM= status. \end{j3note} All images in the connect team, and no others, shall invoke the same OPEN statement with identical values for the s. There is an implicit team synchronization. The OPEN statement connects the file on the invoking images only. If the OPEN statement does not have a FILE= specifier and the unit is not connected to a file, the processor shall connect the same file to the unit on all images in the connect team. If the connect team contains more than one image, the OPEN statement shall (1) have an ACCESS= specifier that evaluates to DIRECT or (2) have an ACTION= specifier that evaluates to WRITE, and shall not specify an ACCESS= specifier or shall have an ACCESS= specifier that evaluates to SEQUENTIAL. NOTE 9.21a Writing to a sequential file from more than one image without using synchronization is permitted, but is only useful for situations in which the ordering of records is unimportant. An example is for diagnostic output that is labeled with the image index. [end NOTE]" COMMENT FROM THE EDITOR: According to my understanding, team sync plus FLUSH can be used to control the ordering of records. I hope I understand correctly! Note duly reworded. NOTE FROM THE EDITOR: Deleted "An OPEN statement on a unit connected to a file by a previously executed OPEN statement shall have the same connect team as currently in effect." following advice from subgroup. NOTE FROM THE EDITOR: Deleted note 9.21b, as it is part of the confusion about whether units, and therefore connections, are global or not. "Preconnected units and the units identified by the values INPUT_UNIT, OUTPUT_UNIT, and ERROR_UNIT in the intrinsic module ISO_FORTRAN_ENV have a connect team consisting of all the images. If an image with index greater than one executes an input/output statement on one of these units, it shall be a WRITE or PRINT statement. J3 TECHNICAL NOTE Prohibiting INQUIRE seems ... excessive and unwarranted to say the least. Subgroup agree, but there is still a question-mark over other i/o statements. (BACKSPACE, ENDFILE, WAIT, FLUSH, CLOSE, OPEN, REWIND). J3 TECHNICAL NOTE Since READ is prohibited except on image one, in what way does INPUT_UNIT have a connect team (since no-one can do anything)? Surely it would be simpler if its connect term were image 1 only? NOTE 9.21c The input unit identified by * is therefore only available on the image with index one. [end NOTE]". 06-138r2: [181:43] 9.4.5, second constraint (C904) after BNF R907 , Replace "A " With "If the NEWUNIT= specifier does not appear, a " 06-138r2: [181:44+] 9.4.5, after all 3 constraints following BNF R907, Insert a new constraint: "C905a (R904) If a NEWUNIT= specifier appears, a shall not appear.". NOTE TO THE EDITOR: This had, and existing C903-C905 all have, the wrong reference - they all need to reference the BNF rule with the since R905 is only a single . 06-138r2: [182:3+] 9.4.5, after paragraph "If the STATUS= specifier has the value ...", Insert a new paragraph "If the NEWUNIT= specifier appears in an OPEN statement, either the FILE= specifier shall appear, or the STATUS= specifier shall appear with a value of SCRATCH. The unit identified by a NEWUNIT value shall not be preconnected." 06-138r2: (modified by 06-154r4:) [183:32+] Immediately before subclause 9.4.5.10 PAD= specifier in the OPEN statement, Insert a new subclause (renumbering subsequent subclauses of 9.4.5) "<<9.4.5.10 NEWUNIT= specifier in the OPEN statement>> The variable is defined with a processor determined NEWUNIT value if no error occurs during the execution of the OPEN statement. If an error occurs, the processor shall not change the value of the variable. A NEWUNIT value is a negative number, and shall not be -1, ERROR_UNIT, INPUT_UNIT, OUTPUT_UNIT, any value used by the processor for the unit argument to a user-defined derived-type input/output procedure, nor any previous NEWUNIT value that identifies a file that is currently connected." 05-174r3: [185:19+] 9.4.6 The CLOSE statement, after the last paragraph, append "Execution of a CLOSE statement on a unit whose connect team contains more than one image performs a team synchronization after the wait operation.". NOTE FROM THE EDITOR: Fixed to remove the lie. And removed the unnecessary FLUSH (if we don't need to flush in the single-image case, we don't need to flush in the multiple-image case - the file is being closed!). 06-138r2: [201:12] 9.5.3.7.2 User-defined derived-type input/output procedures, after the first bullet list, Replace Note 9.44 "Because the unit argument ... intrinsic module (13.8.2)." With "<> The argument passed to a user-defined derived-type input/output procedure will be negative when the parent input/output statement specified an internal unit, or specified an external unit that is a NEWUNIT value. When an internal unit is used with the INQUIRE statement, an error condition will occur, and any variable specified in an IOSTAT= specifier will be assigned the value IOSTAT_INQUIRE_INTERNAL_UNIT from the ISO_FORTRAN_ENV intrinsic module (13.8.2)." 06-174r3: [208:4+] 9.7.1 BACKSPACE statement, append new paragraph to subclause "A BACKSPACE statement shall not reference a unit whose connect team has more than one image.". 06-174r3: [208:19+] 9.7.2 ENDFILE statement, append new paragraph to subclause "An ENDFILE statement shall not reference a unit whose connect team has more than one image.". 06-174r3: [208:23+] 9.7.3 REWIND statement, append new paragraph to subclause "A REWIND statement shall not reference a unit whose connect team has more than one image.". 06-174r3: [209:18] 9.8 FLUSH statement, second paragraph ("Execution of a FLUSH ..."), prepend to paragraph "Execution of a FLUSH statement causes data written to an external unit to be made available to other images of the unit's connect team which execute a FLUSH statement in a subsequent segment for that unit." And change "Execution of a FLUSH statement causes" to "It also causes". NOTE FROM THE EDITOR: (1) The edit's attempted merger of the new functionality with the old made it hard to follow, so I've separated it out. (2) Flaw: It claimed that FLUSH on the writing image made it available ... contradicted by the later statement about FLUSH on the reading image. (3) Flaw: It did not mention anything about the reading image FLUSH needing to be subsequent to the writing image FLUSH. (4) Flaw: It changed the existing "means other than Fortran" to "other processes", which is not correct. (The term "other processes" is not defined, but obviously does not include C routines that are part of a single-threaded program being executed.) (5) Flaw: It said "same connect team" but not which connect team; since an image can be part of multiple connect teams it should say which one. My replacement might also be flawed, but I think it is closer. (6) Used "subsequent segment" instead of "succeeding segment" since I think that reads better. Also changed Note 8.29 to use those words. 06-138r2: [211:8-9] 9.9.1 Inquiry specifiers, paragraph following the constraints, Replace whole paragraph "The value of shall be ... intrinsic module (13.8.2)." With "If identifies an internal unit (9.5.3.7.2), an error condition occurs.". 06-174r3: [213:18] 9.9.1.16 NEXTREC= specifier in the INQUIRE statement, append to subclause "J3 TECHNICAL NOTE NEXTREC= does not have a well-defined meaning in the context of a unit opened with the TEAM= specifier." 06-138r2: [218:25+] 9.10.4 IOSTAT= specifier, numbered list, after item (1), Add a new list item, and renumber the rest of the list: "(2) The processor-dependent positive integer value of the constant IOSTAT_INQUIRE_INTERNAL_UNIT if an error occurred due to a unit number identifying an internal file being used in an INQUIRE statement.". 06-138r2: [218:26] 9.10.4, numbered list, second list item (third after previous edit), After "processor-dependent positive integer value" Insert ", different from IOSTAT_INQUIRE_INTERNAL_UNIT,", And Replace "an error" with "any other error". 06-139r1: [219:10] 9.11 Restrictions on input/output statements, third paragraph, After "an external unit" insert "that is identified by another input/output statement being executed". 05-275r3: [221:15+] 10.1.1 FORMAT statement, R1002 , add a new production "<> ( [ , ] )" 05-275r3: [222:13+] 10.2 Form of a format item list, after R1004 , add a new rule "R1004a <> *()" 05-275r3: [223:9] 10.2.1 Edit descriptors, R1005 , Change "G . [ E ]" to "G [ . [ E ] ]" 05-275r3: [223:20] 10.2.1, Second constraint (C1006) after R1010 , Change "and F" to "F, and G" 05-275r3: [223:21+] 10.2.1, After the second constraint (C1006) after R1010 , Add a new constraint "C1006a (R1005) For the G edit descriptor, shall be specified if and only if is not zero." 05-275r3: [225:13-15] 10.3 Interaction between input/output list and format, last paragraph (before Note 10.6) Delete the sentence "However, if another ... processed (10.7.2)." 05-275r3: [225:15] 10.3, last paragraph (before Note 10.6), Change "Format control then" to "Otherwise, format control" 05-275r3: [225:20] 10.3, last paragraph (before Note 10.6), after the penultimate sentence (which ends "... specification is reused.") insert a new sentence: "If format control reverts to a parenthesis that is not the beginning of an , the file is positioned in a manner identical to the way it is positioned when a slash edit descriptor is processed (10.7.2)." 05-275r3: [225:22-] 10.3, at the very end after Note 10.6, add a new note: "Note 10.6a The effect of an is as if its enclosed list were preceded by a very large repeat count. There is no file positioning implied by reversion. This may be used to write what is commonly called a comma separated value record. For example, WRITE( 10, '( "IARRAY =", *( I0, :, ","))') IARRAY produces a single record with a header and a comma separated list of integer values." 06-175r2: [226:23] 10.6 Data edit descriptors, second numbered list, item (2), Change "or logical" to "logical, or bits". 06-175r2: [226:29] In the paragraph immediately before 10.6.1 Numeric editing, after "numeric, logical" insert ", bits". 06-175r2: [226:31] 10.6.1 Numeric editing, change name of subclause to "Numeric and bits editing". 06-175r2: [226:33] 10.6.1, first sentence, Change "and complex" to "complex, and bits". 05-275r3: [227:13] 10.6.1 Numeric editing, numbered list, item (6) Change "and F editing," to "F, and G editing,". 06-175r2: [227:17] 10.6.1.1 Integer editing, first sentence, Change "I, I" to "I and I", Delete "B, ... and Z". NOTE FROM THE EDITOR: IT IS UTTERLY UNACCEPTABLE TO BLOCK-REPLACE WHOLE SWATHES OF TEXT. ACCURATE EDITING INSTRUCTIONS ARE REQUIRED. 06-175r2: [227:19] 10.6.1.1, first paragraph, penultimate sentence, After "shall be of type integer" insert "or bits". 06-175r2: [227:19-20] 10.6.1.1, first paragraph, last sentence, Change "G edit descriptor" to "G, B, O, and Z edit descriptors", Change "(10.6.4.1.1)" to "(10.6.5.1.1, 10.6.1.3)", NOTE: 10.6.1.3 is the new subclause entitled "Bits editing". 06-175r2: [227:20+] 10.6.1.1, after the first paragraph, insert new paragraph "If the input list item is of type bits, the input field is edited as if the input list item were of type integer and bits compatible with the actual list item, followed by the effect of an intrinsic assignment of the resulting integer value to the actual list item. J3 TECHNICAL NOTE (1) This is misplaced and/or misguided. The type and kind of the input item do not affect input editing. Nor does input editing define the list item, that is "data transfer" (9.5.3.4 and in particular 9.5.3.4.2). J3 TECHNICAL NOTE (2) This proposal appears to be requiring unsigned integers by the back door. However, since we don't actually have unsigned integers it does not work. Consider, for example, an 8-bit bits variable, reading the value "130". According to the above, this is equivalent to reading it into a one-byte integer - but that is not valid, 130 not being in the set of values. So it may fail. J3 TECHNICAL NOTE (4) This feature is unusable by the normal user. If he has a bits variable of KIND==7, what is the effect? It is all very well saying "as if" there was an integer variable of the right kind, but that kind is not guaranteed to exist and might well not exist.". 06-175r2: [227:22-23] 10.6.1.1, third paragraph, first sentence, Between " (R408)" and ",", Insert "if the list item is of type integer and a (R409) if the list item is of type bits, except for the interpretation of blanks." NOTE FROM THE EDITOR: Extra edit, don't allow signs on unsigned integer input. This might or might not be necessary... 06-175r2: [227:23-26] 10.6.1.1, third paragraph, Delete "For the B, O, ... corresponding upper-case hexadecimal digits.". 06-175r2: [227:26+] 10.6.1.1, after the third paragraph, insert new paragraph "If the output list item is of type bits, its value is interpreted as a nonnegative integer (13.3).". 06-175r2: [227:28] NOTE FROM THE EDITOR: I HAVE NOT ACCEPTED THE EDIT TO DELETE "otherwise". 06-175r2: [227:30-32+1] 10.6.1.1, fifth paragraph and following note, Delete the paragraph and note "The output field for the B ... one digit.". 06-175r2: [227:33-34] 10.6.1.1, sixth paragraph, Delete ", B ... Z", Delete ", B ... Z", Delete ", respectively". 06-175r2: [227:36] NOTE FROM THE EDITOR: I HAVE NOT ACCEPTED THE EDIT TO CHANGE "is zero" TO "consists of all zero bits". AN INTEGER DOES NOT CONSIST OF BITS. 06-175r2: [228:4-5] 10.6.1.2, first paragraph, last sentence, Change "G edit descriptor" to "G, B, O, and Z edit descriptors". NOTE FROM THE EDITOR: THIS DIFFERS FROM THE VERSION IN THE PAPER. IT WOULD BE INCONSISTENT TO ALLOW B/O/Z TO EDIT REAL DATA WITHOUT ALLOWING IT TO EDIT COMPLEx DATA. 06-175r2: [232:21-] Immediately before 10.6.2 Logical editing insert new subclause "10.6.1.3 Bits editing The B, B, O, O, Z, and Z edit descriptors indicate that the field to be edited occupies positions, except when is zero. When is zero, the processor selects the field width. On input, shall not be zero. The input/output list item shall be of type bits, integer, real, complex, or logical. The G edit descriptor (10.6.4.1a) or the I edit descriptor (10.6.1.1) also can be used to edit bits data." NOTE FROM THE EDITOR: Added complex and logical to the list above for consistency. This does not affect the treatment of complex taking two edit descriptors. "If the input list item is not of type bits, the input field is edited as if the input list item were of type bits and bits compatible with the actual list item. On input, m has no effect. In the input field for the B, O, and Z edit descriptors the character string shall consist of binary, octal, or hexadecimal digits (as in R428c, R428d, R428e) in the respective input field. The lower-case hexadecimal digits a through f in a hexadecimal input field are equivalent to the corresponding upper-case hexadecimal digits. If the output list item is not of type bits, it is first converted to a list item of type bits that is bits compatible with it. If the output list item, , is not of type bits, it is interpreted as if it were of type bits with the value BITS(). The output field for the B, O, and Z descriptors consists of zero or more leading blanks followed by the internal value in a form identical to the digits of a binary, octal, or hexadecimal constant, respectively, with the same value and without leading zeros. Note 10.13a A binary, octal, or hexadecimal constant always consists of at least one digit or hexadecimal digit. [end Note] R10xx <> [ ] ... The output field for the B, O, and Z edit descriptor is the same as for the B, O, and Z edit descriptor, except that the or consists of at least digits. If necessary, sufficient leading zeros are included to achieve the minimum of digits. The value of shall not exceed the value of , except when is zero. If is zero and the internal value consists of all zero bits, the output field consists of only blank characters. When and are both zero, and the internal value consists of all zero bits, one blank character is produced.". 05-275r3: [233:20] 10.6.4 Generalized editing, first paragraph, first sentence, Change "The G. and G. E" to "The G, G., and G. E". 05-275r3: [233:21] 10.6.4, first paragraph, second sentence, Change "These" to "When is nonzero, these". 06-175r2: [233:23] 10.6.4, first paragraph, last sentence, After "integer, logical" insert ", bits". 05-275r3: [233:23] 10.6.4, first paragraph, append new sentences "When is zero the processor selects the field width. On input, shall not be zero." 05-275r3: [233:25] 10.6.4.1 Generalized numeric editing, only paragraph, only sentence, Change "G. and G. E" to "G, G., and G. E". 05-275r3: [233:29] 10.6.4.1.1 Generalized integer editing, only paragraph, only sentence, Append "When used to specify the output of integer data, the G0 edit descriptor follows the rules for the I0 edit descriptor.". 05-275r3: [234:1-] 10.6.4.1.2 Generalized real and complex editing, after the first paragraph, insert a new paragraph: "When used to specify the output of real or complex data, the G0 edit descriptor follows the rules for the ES. E edit descriptor. Reasonable processor-dependent values of , , and are used with each output value." 05-275r3: [234:1] 10.6.4.1.2, second paragraph, only sentence, After "output field" insert "for the G. and G. E edit descriptors". 06-175r2: [234:13-] Immediately before 10.6.4.3 Generalized logical editing, insert new subclause "10.6.4.1a Generalized bits editing When used to specify the input/output of bits data, the G and GE edit descriptors follow the rules for the Zw edit descriptor (10.6.1.3), except that shall not be zero. When used to specify the output of bits data, the G0 edit descriptor follows the rules for the Z0 edit descriptor.". 05-275r3: [234:15] 10.6.4.2 Generalized logical editing, only paragraph, append sentence "When used to specify the output of logical data, the G0 edit descriptor follows the rules for the L1 edit descriptor.". 05-275r3: [234:18] 10.6.4.3 Generalized character editing, only paragraph, append sentence "When used to specify the output of character data, the G0 edit descriptor follows the rules for the A edit descriptor with no field width." 06-175r2: [237:37] 10.7.6 BN and BZ editing, second paragraph, first sentence, Replace "in numeric input fields" with "in numeric and bits input fields". 06-175r2: [237:42-43] 10.7.6, third paragraph, first sentence, After "affects only numeric" insert "and bits", Change "and" to ",", Before "on input" insert "and generalized bits editing (10.6.4.1a)". 06-175r2: [239:19+] 10.9.1 List-directed input, after the third paragraph (which begins "When the next effective item is of type integer"), insert new paragraph "When the next effective item is of type bits, the value in the input record is interpreted as if a Z edit descriptor with a suitable value of were used.". 06-175r2: [241:10+] 10.9.2 List-directed output, after the fourth paragraph (which begins "Integer output"), insert new paragraph: "Bits output constants are produced with the effect of a Z edit descriptor with equal to ( + 3)/4 where is the kind type parameter value of the list item". NOTE FROM THE EDITOR: Revised to standardise the value of since, unlike integers, leading zero bits are significant. 06-175r2: [241:15-16] SUPERCEDED 10.9.2, sixth paragraph (beginning "For numeric output,"), After both occurrences of "numeric" insert "and bits". NOTE: Superceded by the change to the edit at [241:10+]. 06-175r2: [243:36] 10.10.1.2 Namelist input values, first sentence, after "list items of types logical, integer," insert "bits,". 06-175r2: [244:37+] 10.10.1.3 Namelist group object list items, after the fourth paragraph (which begins "When the next effective item is of type integer"), insert new paragraph "When the next effective list item is of type bits, the value in the input record is interpreted as if a Z edit descriptor with a suitable value of were used.". 06-175r2: [246:14+] 10.10.2.1 Namelist output editing, after the second paragraph (which begins "Integer output"), insert new paragraph "Bits output constants are produced with the effect of a Z edit descriptor with equal to ( + 3)/4 where is the kind type parameter value of the list item.". NOTE FROM THE EDITOR: Revised in accordance with the revision to list-directed. 06-175r2: [247:2-3] DELETED 10.10.2.1, fourth para (which begins "For numeric output"), After both occurrences of "numeric" insert "and bits". SUPERCEDED by the revision to [246:14+]. TR 19767: [249:3] 11 Program units, first paragraph, second sentence, after "module", insert ", a submodule". TR 19767: [249:4] 11 Program units, second paragraph, first sentence, after "modules" insert ",submodules". 05-196: [250:14] 11.2 Modules, BNF R1107 "", Delete first "". TR 19767: [250:17+] 11.2 Modules, BNF R1108 , add another alternative "<> ". TR 19767: [251:8] 11.2.1 The USE statement and use association, first paragraph, append "A submodule shall not reference its ancestor module by use association, either directly or indirectly. Note 11.6a It is possible for submodules with different ancestor modules to access each others' ancestor modules by use association.". 06-168r2: [251:10] 11.2.1 The USE statement and use association, first paragraph, first sentence, before "and namelist groups" insert "macros,". NOTE TO THE EDITOR: Immediately before this delete the pointless cross-ref for generic identifiers. TR 19767: [253:2-] Immediately before 11.3 Block data program units, insert new subclause "11.2.2 Submodules A <> is a program unit that extends a module or another submodule. The program unit that it extends is its <>, and is specified by the in the . A submodule is a <> of its parent. An <> of a submodule is its parent or an ancestor of its parent. A <> of a module or submodule is one of its children or a descendant of one of its children. The <> is the ordered pair whose first element is the ancestor module name and whose second element is the submodule name. Note 11.6b A module and its submodules stand in a tree-like relationship one to another, with the module at the root. Therefore, a submodule has exactly one ancestor module and may optionally have one or more ancestor submodules. {end note} A submodule accesses the scoping unit of its parent by host association. A submodule may provide implementations for module procedures, each of which is declared by a module procedure interface body (12.3.2.1) within that submodule or one of its ancestors, and declarations and definitions of other entities that are accessible by host association in descendant submodules. R1115a <> [ ] [ ] R1115b <> SUBMODULE ( ) R1115c <> [ : ] R1115d <> END [ SUBMODULE [ ] ] C1114a (R1115a) An automatic object shall not appear in the of a submodule. C1114b (R1115a) A submodule shall not contain a \obs{or a }. C1114c (R1115a) An object with default initialization that is declared in the of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. C1114d (R1115c) The shall be the name of a nonintrinsic module; the shall be the name of a descendant of that module. C1114e (R1115a) If a is specified in the , it shall be identical to the specified in the .". 05-273r3: [256:28] 12.2.1.1 Characteristics of dummy data objects, Change "VALUE(...), ASYNCHRONOUS(...)," to "ASYNCHRONOUS(5.1.2.3), CONTIGUOUS(5.1.2.3a), VALUE(5.1.2.15)," 05-273r3: [257:3] 12.2.2 Characteristics of function results, After "whether it is a pointer," insert "whether it has the CONTIGUOUS attribute,". TR 19767: [257:13] 12.3 Procedure interface, first paragraph, last sentence, after "units" insert ", except that for a separate module procedure body ({ref to new 12.5.2.4}), the dummy argument names, binding label, and whether it is recursive shall be the same as in its corresponding module procedure interface body (12.3.2.1)". 06-174r3: [257:25+] 12.3.1.1, Explicit interface, numbered list item 1, itemized list therein, add new subitem "(a1) With an argument that is a co-indexed object (2.4.5a),". NOTE FROM THE EDITOR: This makes old (F77-style) procedures useless for operating on co-indexed objects. I'm not convinced it is necessary. 06-174r3: [257:33+] 12.3.1.1, numbered list item 2, itemized list therein, add new subitem "(b1) is a co-array,". TR 19767: [259:20] 12.3.2.1 Interface block, penultimate constraint (C1210), after "allowed only in an " insert "that is not a module procedure interface body". TR 19767: [259:30+] 12.3.2.1, after third paragraph after the last constraint (C1211) (i.e. after "; otherwise, it is an external procedure.") insert new paragraph and constraint: "A <> is an interface body whose initial statement contains the keyword MODULE. It declares the <> for a separate module procedure ({ref new 12.5.2.4}). A separate module procedure is accessible by use association if and only if its interface body is declared in the specification part of a module and is public. If a corresponding ({ref new 12.5.2.4}) separate module procedure is not defined, the interface may be used to specify an explicit specific interface but the procedure shall not be used in any way. C1211a (R1201) A module procedure interface body shall not appear in an abstract interface block.". 05-279: [264:19] 12.3.2.3 Procedure declaration statement, BNF R1214 , replace BNF with "R1214 <> => R1214a <> <> R1214b <> ". 05-279: [264:30+] 12.3.2.3, After the fifth constraint after R1215 (the one that begins "If => appears ...") Insert new constraint "C1216a (R1214b) The shall be the name of an initialization target.". 05-279: [265:15-] 12.3.2.3, before the last non-note paragraph (begins "If => ...") insert new paragraph "A procedure is an initialization target if it is a nonelemental external or module procedure, or a specific intrinsic function listed in \ref{D13:Specific names for standard intrinsic functions} and not marked with a bullet ($\bullet$).". 05-279: [265:15-18] 12.3.2.3, last non-note paragraph, Replace with several paragraphs: "If => appears in a in a it specifies the initial association status of the corresponding procedure entity, and implies the SAVE attribute. The SAVE attribute may be confirmed by explicit use of the SAVE attribute in the , by inclusion of the procedure entity name in a SAVE statement (\ref{D5:SAVE statement}), or by the appearance of a SAVE statement without a in the same scoping unit. If => appears, the procedure entity is initially disassociated. If => appears, the procedure entity is initially associated with the target. If has an explicit interface, its characteristics shall be the same as except that may be pure even if is not pure and may be an elemental intrinsic procedure. If the characteristics of or are such that an explicit interface is required, both and shall have an explicit interface. If has an implicit interface and is explicitly typed or referenced as a function, shall be a function. If has an implicit interface and is referenced as a subroutine, shall be a subroutine. If and are functions, they shall have the same type; corresponding type parameters shall either both be deferred or both have the same value.". 06-174r3: [266:27+] 12.4 Procedure reference, immediately before BNF R1220 , insert new paragraph "If the in a is a co-indexed object, the procedure referenced is on the executing image." NOTE FROM THE EDITOR: REJECTED AS BEING COMPLETELY MEANINGLESS. PROCEDURES ARE NOT IN THE SET OF ENTITIES THAT ARE "PER-IMAGE". THERE IS ONLY ONE PROCEDURE. IF YOU MEAN THAT THE EXECUTING IMAGE EXECUTES IT, SURE, THAT IS WHAT EXECUTING A PROCEDURE REFERENCE ***MEANS***. I.E., I COULD REWORD IT AS "If an image executes a procedure reference, that image executes the procedure reference." THIS IS TOO OBVIOUS EVEN TO BE A NOTE, LET ALONE NORMATIVE. SUGGESTED ALTERNATIVE: "Note 12.xx If the in a is a co-indexed object, although the procedure pointer is fetched from the specified image, the reference occurs on the executing image." Ugh. Still not pretty. "Note 12.xx If image executes a procedure reference in which the if a specifies a procedure pointer on image , the procedure pointer association is fetched from image but the invocation of the associated procedure occurs on image ." is more explicit but overly verbose. 05-202r1: [267:15-17] 12.4 Procedure reference, fifth constraint C1229 after BNF R1222 , Replace whole constraint ("A ... bullet(o).") by "C1229 (R1221) A shall be the name of an external, internal, module, or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet (o), or a procedure pointer." 05-202r1: [267:17+1-7] 12.4 Procedure reference, first note 12.16, Delete entire note ("Note 12.16 This standard does not allow..."). 06-176: [268:1+] 12.4.1 Actual arguments, dummy arguments, and argument association, immediately after the subclause heading, Insert new subclause "12.4.1.1a Argument correspondence" 05-210r2: [268:2-15] 12.4.1, throughout first paragraph, use "correspond" in the appropriate form instead of "associate". In detail: - Replace "is associated with" by "corresponds to" at [268:5], [268:7-8], [268:9], and [268:10]. - Replace "be associated with" by "correspond to" at [268:13], [268:14], and [268:15]. 05-210r2: (superceded by edit from 06-176 below) [268:15+] 12.4.1, after the first paragraph, add a new paragraph. 06-149: (superceded by edit from 06-176 below) [268:15+] Change the new paragraph inserted by 05-210r2. 06-176: [268:16] 12.4.1.1 The passed-object dummy argument and argument association, In the title, change "association" to "correspondence". [268:18] In the only sentence, change "is associated" to "corresponds". 06-176: [268:19+] Immediately before 12.4.1.2 Actual arguments associated with dummy data objects, insert a new subclause "12.4.1.1b Argument association Except in references to intrinsic inquiry functions, if a nonoptional nonpointer dummy argument corresponds to a pointer actual argument, the actual argument shall be pointer associated with a target and the dummy argument becomes argument associated with that target. If an optional nonpointer dummy argument corresponds to a pointer actual argument that is pointer associated with a target the dummy argument becomes argument associated with that target. A present nonpointer dummy argument that corresponds to a nonpointer actual argument becomes argument associated with that actual argument. A present pointer dummy argument that corresponds to a pointer actual argument becomes argument associated with that actual argument. A present pointer dummy argument that does not correspond to a pointer actual argument is not argument associated.". 06-175r2: [268:21] 12.4.1.2 Actual arguments associated with dummy data objects, first sentence, after "it shall be type compatible" insert "or bits compatible". 06-175r2: [269:1] 12.4.1.2, second normative paragraph, first sentence, Before "type parameter values" Change "The" to "Unless the actual argument and the corresponding dummy argument are bits compatible, the". After paragraph insert "J3 TECHNICAL NOTE. BROKEN. "bits compatible" is not a symmetric relationship, so this is not well-defined." 06-174r3: [269:13+] 12.4.1.2 Actual arguments associated with dummy data objects, after the fifth paragraph, add a new paragraph and note: "If the actual argument is a co-indexed object, the dummy argument shall not be a co-array and shall have the INTENT(IN) or the VALUE attribute." NOTE FROM THE EDITOR: The second sentence was subtly incorrect; after correction, it was covered by the revised C613b above and so deleted. "NOTE 12.21a If the actual argument is a co-indexed object and the corresponding dummy argument is not a co-array, it is likely that a processor will make a copy on the executing image of the actual argument, including copies of any allocated allocatable subcomponents, before argument association occurs. [end NOTE] J3 TECHNICAL NOTE It doesn't seem like forcing the user to write localvar = x[i] CALL sub(localvar) x[i] = localvar is a substantial improvement in, well, anything. Not to mention that the user cannot do that if x[i] is undefined or only partially defined before the call to sub. It doesn't seem to be any more work for the processor than what it already does for CALL sub(a(1:n:2)) for explicit-shape dummies. And, MUCH WORSE, this makes defined assignment unusable with co-arrays. Can we say "not even integrated with Fortran 90"? 06-108r1: [269:14-] 12.4.1.2 Actual arguments associated with dummy data objects, immediately before the sixth normative paragraph, Insert new paragraph "If the dummy argument is a pointer that does not have the INTENT(IN) attribute, the actual argument shall be a pointer. Otherwise, the actual argument shall be a pointer or a valid target for the dummy pointer in an assignment statement. If the actual argument is not a pointer, the dummy pointer becomes pointer-associated with the actual argument." 06-108r1: [269:14] 12.4.1.2, sixth normative paragraph, Replace "If the dummy argument is a pointer, the actual argument shall be a pointer and" with "If the dummy argument and the actual argument are pointers," 06-175r2: [269:14-15] Includes edit from 06-108r1, replace that whole sentence with "If the dummy argument and the actual argument are pointers, the ranks shall agree and either the nondeferred type parameters shall agree or the actual argument and the dummy argument shall be bits compatible. J3 TECHNICAL NOTE Argument-associating pointers of different types does not seem to be in accordance with the spirit of our current rules. It requires a processor to use the same representation for pointers of different kinds or to do copyin/copyout conversions. Why are we doing this?" 05-273r3: [269:15] 12.4.1.2, sixth normative paragraph, Before "If a dummy argument is allocatable" insert "If a dummy pointer has the CONTIGUOUS attribute, the actual argument shall have the CONTIGUOUS attribute." 06-175r2: [269:16] 12.4.1.2, sixth paragraph, sentence beginning "If a dummy argument is allocatable", Change "and the nondeferred type parameters and ranks shall agree" To ", the ranks shall agree, and either the nondeferred type parameters shall agree or the actual argument and the dummy argument shall be bits compatible J3 TECHNICAL NOTE Argument-associating allocatables of different types does not seem to be in accordance with the spirit of our current rules. It requires a processor to use the same representation for allocatables of different kinds or to do copyin/copyout conversions. Why are we doing this?" [271:12-] 12.4.1.2, at the very end, insert new subclause "12.4.1.2a Co-array arguments The actual argument shall be an allocatable co-array if and only if the dummy argument is an allocatable co-array with the same rank and co-rank. If a dummy argument is a nonallocatable co-array, the co-rank and co-bounds are specified by the local declaration and are independent of those of the actual argument. The actual argument shall be a co-array or a subobject of a co-array without any co-subscripts, vector-valued subscripts, allocatable component selection, or pointer component selection. J3 TECHNICAL NOTE BROKEN. I ASSUME YOU WANT TO BE ABLE TO PASS VARIABLE%CO_ARRAY_COMPONENT TO A DUMMY CO-ARRAY, NO?" NOTE TO THE EDITOR: Subgroup says yes. It's not entirely trivial to fix the wording though. (It probably needs to be something like "no part_ref after the part_ref with co-rank non-zero shall have the pointer or allocatable attribute, or have a vector-valued subscript".) "NOTE 12.21b The co-array on the executing image is specified as the actual argument and this is associated with the dummy co-array argument on the same image. There are corresponding co-arrays on the other images. For example: INTERFACE SUBROUTINE SUB(X,Y) REAL :: X(:)[*], Y(:)[*] END SUBROUTINE SUB END INTERFACE ... REAL, ALLOCATABLE :: A(:)[:], B(:,:)[:] ... CALL SUB(A(:),B(1,:)) [end NOTE] Note 12.xx The bounds and co-bounds of a dummy co-array may differ on each image executing a reference to the procedure. A co-indexed always uses the bounds and co-bounds on the executing image." NOTE FROM THE EDITOR: Replaced nonsense and confusion with a note. "If an assumed-shape co-array that does not have the CONTIGUOUS attribute or a subobject of an assumed-shape co-array that does not have the CONTIGUOUS attribute is an actual argument associated with a dummy co-array, the dummy co-array shall be of assumed shape. If an array section is an actual argument associated with a dummy co-array that is not of assumed shape or has the CONTIGUOUS attribute, the section shall be contiguous (\ref{D5:CONTIGUOUS attribute}). NOTE 12.21d The constraints on actual arguments that correspond to a dummy co-array that is not of assumed-shape or has the CONTIGUOUS attribute are designed to avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism. [end NOTE] J3 TECHNICAL NOTE This appears to be unnecessary without some relaxation in the rules in 12.4.1.7 (the "high performance" rules for Fortran dummy arguments).". 05-210r2: [269:20-22] 12.4.1.2, Delete the eighth normative paragraph "Except in references ... with that target.". (The first paragraph starting "Except in references".) 06-149: [269:20] 12.4.1.2, paragraph deleted by edit from 05-210r2, Before "dummy argument is not a pointer" Replace "the" with "a nonoptional". 06-149: [269:22] 12.4.1.2, same deleted paragraph, append a new sentence: "If an optional dummy argument that is not a pointer is associated with a pointer actual argument, the pointer association status of the actual argument shall not be undefined.". 06-149: [269:23] 12.4.1.2, paragraph beginning "Except in references to intrinsic inquiry functions, if the dummy argument is not allocatable ..." Before "dummy argument is not allocatable" change "the" to "a nonoptional", Before "actual argument is allocatable" insert "corresponding". 05-273r3: [270:5-6] 12.4.1.2, paragraph beginning "If the dummy argument has the TARGET attribute, does not have the VALUE attribute...", Replace "either a scalar or an assumed-shape array" with "either a scalar or an assumed-shape array that does not have the CONTIGUOUS attribute." 06-174r3: [270:7] 12.4.1.2, the first paragraph that begins "If the dummy argument has the TARGET attribute", after "but is not" change "an" to "a co-indexed object or". 06-108r1: [270:13] 12.4.1.2, paragraph beginning "If the dummy argument has the TARGET attribute and is an explicit-shape array" Before "or is an assumed-size" Insert ", is an assumed-shape array with the CONTIGUOUS attribute, ". NOTE TO EDITOR: Better edit is probably to replace the "or is" with ", an assumed-shape array with the CONTIGUOUS attribute, or". 05-210r2: [270:38-39] 12.4.1.2, paragraph beginning "If a nonpointer dummy argument has INTENT(OUT)..." - replace "actual argument" by "argument associated entity" - replace "corresponding actual argument by "argument associated entity". 06-174r3: [271:6] 12.4.1.2, penultimate constraint (C1232), NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS BOTH INCORRECT AND WRONG. COMMENT: A co-indexed object cannot be associated with a VOLATILE dummy anyway. Insert after the ultimate constraint "J3 TECHNICAL NOTE Probably need this constraint: C1233a An actual argument that is a co-indexed object shall not be associated with a dummy argument that has the ASYNCHRONOUS attribute. It is true that allowing VALUE+ASYNCHRONOUS makes a mockery of the restrictions on ASYNCHRONOUS dummies and note 12.26 about their purpose. But should co-arrays try to be consistent or should they copy this inconsistency?". 05-273r3: [271:8,11] 12.4.1.2, both constraints (C1232 and C1233) following Note 12.25 which begins "For more explanatory ...", After "shall be an assumed-shape array" insert "that does not have the CONTIGUOUS attribute". 05-202r1: [271:12+] 12.4.1.3 Actual arguments associated with dummy procedure entities, Insert a new first paragraph: "If the actual argument is the name of an internal subprogram, the host instance of the dummy argument is the innermost currently executing instance of the host of that internal subprogram. If the actual argument has a host instance the host instance of the dummy argument is that instance. Otherwise the dummy argument has no host instance." 06-176: [271:16-18] 12.4.1.3 Actual arguments associated with dummy procedure entities, second paragraph, first and second sentences, Replace "dummy ... those" with "or dummy procedure, or a specific intrinsic procedure". 05-202r1: [271:16] 12.4.1.3 Actual arguments associated with dummy procedure entities, second paragraph, first sentence, after "external" insert ", internal". 06-176: [272:25] 12.4.1.6 Restrictions on dummy arguments not present, subclause title, replace title with "Argument presence and restrictions on arguments not present". 06-149: [272:26] 12.4.1.6 NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS BOTH UNNECESSARY AND WRONG. 06-149: (superceded by edit from 06-176 below). [272:28-29] 12.4.1.6, first numbered list, make some changes. 06-176: [272:28-30] 12.4.1.6, first numbered list, Replace the list and the first two sentences of its following paragraph (up to "shall be present.") with "\begin{enum} \item does not correspond to an actual argument, \item corresponds to an actual argument that is not present, or \item does not have the ALLOCATABLE or POINTER attribute, and corresponds to an actual argument that \begin{enum} \item has the ALLOCATABLE attribute and is not allocated, or \item has the POINTER attribute and is disassociated. \end{enum} \end{enum} Otherwise, it is present. A nonoptional dummy argument shall be present. If an optional nonpointer dummy argument corresponds to a pointer actual argument, the pointer association status of the actual argument shall not be undefined.". 05-200r1: [273:1-2] 12.4.1.6 Restrictions on dummy arguments not present, item (5) in the second numbered list, change "component ... substring selector" to "subobject selector". 06-174r3: [279:21+] NOTE FROM THE EDITOR: REJECTED IN FAVOUR OF CONSTRAINING CO-ARRAY DECLARATIONS. TR 19767: [280:3+] 12.5.2.1, BNF R1228 , append another alternative "<> MODULE". 06-143: [280:3+] 12.5.2.1, BNF R1228, add another production "<> IMPURE". NOTE TO EDITOR: Sort the productions into alphabetical order by keyword. 06-143: [280:5-] 12.5.2.1, before the second constraint (C1241) after R1228, Insert new constraint: "C1240a (R1227) A prefix shall not specify both PURE and IMPURE.". TR 19767: [280:7+] 12.5.2.1, between constraint C1242 and BNF R1229 , insert "C1242a (R1227) MODULE shall appear only within the or of a module subprogram or of an interface body that is declared in the scoping unit of a module or submodule. C1242b (R1227) If MODULE appears within the in a module subprogram, an accessible module procedure interface having the same name as the subprogram shall be declared in the module or submodule in which the subprogram is defined, or shall be declared in an ancestor of that program unit. C1242c (R1227) If MODULE appears within the in a module subprogram, the subprogram shall specify the same characteristics and dummy argument names as its corresponding ({ref to new 12.5.2.4}) module procedure interface body. C1242d (R1227) If MODULE appears within the in a module subprogram and a binding label is specified, it shall be the same as the binding label specified in the corresponding module procedure interface body. C1242e (R1227) If MODULE appears within the in a module subprogram, RECURSIVE shall appear if and only if RECURSIVE appears in the in the corresponding module procedure interface body.". 06-113: [280:11] 12.5.2.1, immediately after BNF R1230 , Delete constraint C1243 "FUNCTION shall appear ... module function.". 06-143: [281:1] 12.5.2.1, penultimate normative paragraph (after Note 12.37), After "ELEMENTAL appears" add "and IMPURE does not appear". NOTE TO THE EDITOR: Condition is confusing after this edit (A or B and C); think about rewording this. E.g. "If the PURE appears, or the ELEMENTAL appears and IMPURE does not appear, ..." 06-143: [281:3-4] 12.5.2.1, last normative paragraph (before Note 12.38), NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS TECHNICALLY WRONG. 06-113: [282:14-15] 12.5.2.2 Subroutine subprogram, immediately after BNF R1234 , Delete constraint C1248 "SUBROUTINE shall appear ... module subroutine.". 06-143: [282:26] 12.5.2.2, penultimate paragraph, After "ELEMENTAL appears" insert "and IMPURE does not appear". NOTE TO THE EDITOR: Rewrite this to be the same as in [281:1]. 06-143: [282:28-29] 12.5.2.2, last paragraph, NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS TECHNICALLY WRONG. 05-202r1: [282:35] 12.5.2.3 Instances of a subprogram, second paragraph, second sentence, replace "directly" with "by name". 05-202r1: [282:37] 12.5.2.3 Instances of a subprogram, second paragraph, append "If an internal procedure is invoked via a dummy procedure or procedure pointer, the internal procedure has access to the entities of the host instance of that dummy procedure or procedure pointer." TR 19767: [283:1-] Immediately before 12.5.2.4 ENTRY statement, insert new subclause "12.5.2.3a Separate module procedures A <> is a module procedure defined by a , by a whose initial statement contains the keyword MODULE, or by a whose initial statement contains the keyword MODULE. Its interface is declared by a module procedure interface body (12.3.2.1) in the of the module or submodule in which the procedure is defined, or in an ancestor module or submodule. R1234a <> MODULE PROCEDURE [ ] [ ] [ ] R1234b <> END [PROCEDURE []] C1251a (R1234a) The shall be the same as the name of a module procedure interface that is declared in the module or submodule in which the is defined, or is declared in an ancestor of that program unit and is accessible by host association from that ancestor. C1251b (R1234b) If a appears in the , it shall be identical to the in the MODULE PROCEDURE statement. A module procedure interface body and a subprogram that defines a separate module procedure <> if they have the same name, and the module procedure interface is declared in the same program unit as the subprogram or is declared in an ancestor of the program unit in which the procedure is defined and is accessible by host association from that ancestor. A module procedure interface body shall not correspond to more than one subprogram that defines a separate module procedure. Note 12.40a A separate module procedure can be accessed by use association if and only if its interface body is declared in the specification part of a module and is public. {end note} If a procedure is defined by a , its characteristics are specified by the corresponding module procedure interface body. If a separate module procedure is a function defined by a , the result variable name is determined by the FUNCTION statement in the module procedure interface body. Otherwise, the result variable name is determined by the FUNCTION statement in the module subprogram. TR 19767: [283:7] 12.5.2.4 ENTRY statement, second constraint (C1253), replace "" by "a that does not define a separate module procedure". 06-143: [284:18,19] 12.5.2.4, penultimate paragraph, Replace "keyword PURE is" by "keywords PURE and IMPURE are". After "ELEMENTAL is specified" insert "and IMPURE is not specified". TR 19767: [284:37] 12.5.2.6 CONTAINS statement, first paragraph, change first "module" to "module, submodule". 06-143: [286:9] 12.6 Pure procedures, second paragraph, After "ELEMENTAL" insert "and does not have the IMPURE". 05-278r2: (modified by 06-154r4:) [286:31] 12.6, constraint C1272, enumerated list, fourth item (begins "As the or an intrinsic ...") Replace "" by "variable". 06-174r3: [287:7+] 12.6, after the last constraint, add new constraints (before the note) "C1276a A co-indexed object shall not appear in a variable definition context in a pure subprogram. C1276b A pure subprogram shall not contain an image control statement (8.5.1).". 05-237r4: [287:7+] 12.6 Pure procedure, Note 12.44, first sentence, third line, replace "FORALL where" with "FORALL or a DO CONCURRENT construct, where" 05-237r4: [287:7+] 12.6 Pure procedure, Note 12.44, last sentence, replace "referenced in FORALL statements and constructs and within" with: "referenced in FORALL statements and constructs, DO CONCURRENT constructs, and within" 06-143: [287:13] 12.7.1 Elemental procedure declaration and interface, second paragraph, At the end of the second sentence "An elemental subprogram is a pure subprogram", after "subprogram" insert "unless it has the IMPURE". Delete the third sentence "The PURE ... ELEMENTAL .". 06-143: [287:14] NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS TECHNICALLY WRONG. 06-143: [287:15] NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS TECHNICALLY WRONG. 06-143: [287:17] NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS TECHNICALLY WRONG. 06-143: [288:2] NOTE FROM THE EDITOR: I DELETED THIS EDIT AS IT WAS TECHNICALLY WRONG. 06-143: [288:11] 12.7.2 Elemental function actual arguments and results, last sentence in the first (and only normative) paragraph, Replace "in any order" by "in array element order". 06-143: [289:8-9] 12.7.3 Elemental subroutine actual arguments, first paragraph, last sentence, Replace "in any order" by "in array element order". 06-174r3: [291:3] 13 Intrinsic procedures and modules, first paragraph, append new sentence "Some intrinsic subroutines are collective.". NOTE FROM THE EDITOR: Since we are adding a new subclass of intrinsic subroutine, it behooves us to mention it up front. 06-174r3: [291:14] 13.1 Classes of intrinsic procedures, first paragraph, last sentence, Change "standard intrinsic functions are pure" to "inquiry, elemental, and transformational intrinsic functions are pure". NOTE FROM THE EDITOR: REJECTED. COMMENT: (1) We don't require anything of non-standard intrinsic functions. (2) The only standard intrinsic functions you have added are all "inquiry", so there is no reason for this change. 06-174r3: [291:16+] 13.1, after the second paragraph but before the note, insert new paragraph "A <> is one that has an argument of type IMAGE_TEAM (13.8.2). If it is invoked by one image of a team, it shall be invoked by the same statement on all images of the team. There is an implicit team synchronization (8.5.3) at the beginning and end of the execution of a collective subroutine. NOTE 13.6a The subroutine FORM_TEAM forms a team of images. The other collective subroutines return an array of the same shape as the given co-array after having applied an operation on the images in a team. The simple case of wanting the operation to be applied to all the elements of the co-array can easily be programmed, for example REAL FUNCTION GLOBAL_SUM(ARRAY) REAL :: ARRAY(:,:)[*] REAL,SAVE :: TEMP[*] TEMP = SUM(ARRAY) ! Sum on the executing image CALL CO_SUM(TEMP,GLOBAL_SUM) END FUNCTION GLOBAL_SUM Versions with other arguments can be programmed similarly, see C.9a.2. [end NOTE]" 06-174r3: [292:18+] 13.2 Arguments to intrinsic procedures, at the end, append new subclause "13.2.3 Arguments of collective subroutines Each argument of a collective subroutine shall have the same shape on all images of the team. A co-array argument shall have the same bounds on all images of the team. An INTENT(IN) argument of type IMAGE_TEAM shall have a value that was constructed by invoking FORM_TEAM for the team.". 06-175r2: [292:20-24] 13.3 Bit model, first paragraph, replace paragraph with "The bit manipulation and inquiry functions are described in terms of a model for the representation and behaviour of bits on a processor." NOTE FROM THE EDITOR: The characterisation of functions in the paper-suggested edit was incorrect. However, since all this was redundant I simplified it down to an introductory sentence instead. 06-175r2: [292:25] 13.3, second paragraph, Replace "For the purposes of these procedures," with "For an integer,". 06-175r2: [292:28+] 13.3, after the second paragraph (ending "a 32-bit integer."), insert new paragraph "Using the notation of the formula above, the value of an object of type bits and kind is represented as the ordered sequence of bits with the bit at position . The rightmost bit is and the leftmost bit is . Such a bits object can be interpreted as a nonnegative integer with the value .". 05-204r2: [294:25+] 13.5.2 Mathemetical functions, insert new line in list after ACOS: "ACOSH(X) Inverse hyperbolic cosine" 05-204r2: [294:26+] 13.5.2 Mathemetical functions, insert new line in list after ASIN: "ASINH(X) Inverse hyperbolic sine" 06-114r2: [294:27] 13.5.2, ATAN entry in list, After "ATAN(X)" insert "or ATAN(Y,X)". 05-204r2: [294:27+] 13.5.2 Mathemetical functions, insert new line in list after ATAN: "ATANH(X) Inverse hyperbolic tangent" 05-268r3: [294:28+] 13.5.2, insert into list in alphabetical order "BESSEL_J0 (X) Bessel function of the first kind of order zero BESSEL_J1 (X) Bessel function of the first kind of order one BESSEL_JN (N,X) Bessel function of the first kind of order N BESSEL_Y0 (X) Bessel function of the second kind of order zero BESSEL_Y1 (X) Bessel function of the second kind of order one BESSEL_YN (N,X) Bessel function of the second kind of order N ERF (X) Error function ERFC (X) Complementary error function GAMMA (X) Gamma function HYPOT (X,Y) Euclidean distance function LOG_GAMMA (X) Logarithm of absolute value of gamma function" NOTE FROM THE EDITOR: THIS EDIT WAS DEFECTIVE - IT WAS MISSING ALL BUT THE FUNCTION NAMES. 05-264r3: [294:30+] 13.5.2, insert into list in alphabetical order "ERFC_SCALED (X) Exponentially-scaled complementary error function" 06-175r2: [295:29ish] 13.5.4 Kind functions, add two new entries alphabetically "BITS_KIND(X [, KIND]) Bits kind type parameter value, compatible with the argument SELECTED_BITS_KIND(N) Bits kind type parameter value, given number of bits". 06-175r2: [295:36-] 13.5.5 Miscellaneous type conversion functions, add new entry "BITS(A [,KIND]) Convert to bits type". Missing edit from 05-232r1: [295:33-34] 13.5.4 Kind functions, last function, After "[P,R" insert ",RADIX". Change "precision and range" to "precision, range, and radix". 06-174r3: [296:6+] 13.5.7 Array inquiry functions, add alphabetically "CO_LBOUND (CO_ARRAY [, DIM, KIND]) Lower co-bounds of a co-array CO_UBOUND (CO_ARRAY [, DIM, KIND]) Upper co-bounds of a co-array". 05-273r3: [296:15+] 13.5.8 Other inquiry functions, insert into list in order: "IS_CONTIGUOUS(A) Contiguity inquiry" 06-175r2: [296:20-31] 13.5.9 Bit manipulation procedures, add new entries alphabetically "DSHIFTL (I, J, SHIFT) Double left shift DSHIFTR (I, J, SHIFT) Double right shift LEADZ (I [,KIND]) Number of leading zero bits MASKL (I [,KIND]) Left justified bit mask MASKR (I [,KIND]) Right justified bit mask MERGE_BITS (I, J, MASK) Merge bits under mask POPCNT (I [,KIND]) Number of one bits POPPAR (I [,KIND]) Parity of one bits SHIFTA (I, SHIFT) Arithmetic right shift SHIFTL (I, SHIFT) Left shift SHIFTR (I, SHIFT) Right shift TRAILZ (I [,KIND]) Number of trailing zero bits". NOTE FROM THE EDITOR: REJECTED creating new tables for LEADZ et al. If "BTEST" is a bits manipulation procedure (and it is so classed) so is LEADZ too. 06-175r2: [297:4-11] 13.5.12 Array reduction functions, add new entries alphabetically "IALL (ARRAY, DIM [,MASK]) or Bitwise AND of array elements IALL (ARRAY [,MASK]) IANY (ARRAY, DIM [,MASK]) or Bitwise OR of array elements IANY (ARRAY [,MASK]) IPARITY (ARRAY, DIM, [,MASK]) or Bitwise exclusive OR of array elements IPARITY (ARRAY [,MASK]) PARITY (MASK [,DIM]) True if an odd number of values is true". NOTE FROM THE EDITOR: Maybe it's just me, but I'd find these easier to grok if they just said what operation they were reducing by, e.g. "Reduce array with IAND", ... "Reduce array with .NEQV. operator". 05-264r3: [297:9+] 13.5.12 Array reduction functions, insert into list in order: "NORM2 (X) $L_2$ norm of an array". 06-181r1: [297:23+] 13.5.14 Array location functions, insert into list in order: "FINDLOC (ARRAY, VALUE, DIM, [,MASK, KIND, BACK]) or Location of value in FINDLOC (ARRAY, VALUE, [,MASK, KIND, BACK]) an array" 06-181r1: [297:24-25] 13.5.14, entries for MAXLOC and MINLOC, Change "[, MASK, KIND]" to "[MASK, KIND, BACK]" in 4 places. 06-174r3: [297:25+] After 13.5.14 Array location functions, add a new subclause "13.5.14a Collective subroutines CO_ALL(MASK,RESULT[,TEAM]) Whether all values are true CO_ANY(MASK,RESULT[,TEAM]) Whether any value is true CO_COUNT(MASK,RESULT[,TEAM]) Number of true elements in a co-array CO_MAXLOC(CO_ARRAY,RESULT[,TEAM]) Image indices of maximum values CO_MAXVAL(CO_ARRAY,RESULT[,TEAM]) Maximum values CO_MINLOC(CO_ARRAY,RESULT[,TEAM]) Image indices of minimum values CO_MINVAL(CO_ARRAY,RESULT[,TEAM]) Minimum values CO_PRODUCT(CO_ARRAY,RESULT[,TEAM]) Products of elements CO_SUM(CO_ARRAY,RESULT[,TEAM]) Sums of elements FORM_TEAM(TEAM,IMAGES) Forms a team of images". NOTE FROM THE EDITOR: I HAVE DELETED THE NOTE. IF YOU WANT IT, FIND SOMEWHERE ELSE TO PUT IT, NOT IN THE MIDDLE OF THE INTRINSIC SUMMARY TABLES. FURTHER NOTE: I reworded CO_ALL and 05-240r4: [298:6+] 13.5.18 System environment procedures, insert new item alphabetically "EXECUTE_COMMAND_LINE(COMMAND,[WAIT,EXITSTAT,CMDSTAT,CMDMSG]) Execute a command line". 06-174r3: [298:9+,11+,12+] 13.5.18, add three new items alphabetically "IMAGE_INDEX(CO_ARRAY, SUB) Index of an image NUM_IMAGES() Number of images THIS_IMAGE( ) or Index of the invoking image THIS_IMAGE(CO_ARRAY [,DIM]) Co-subscript list J3 TECHNICAL NOTE THESE TWO USES ARE LIKE, TOTALLY DIFFERENT, MAN. CONSIDER CHANGING THE NAME OF THE SECOND ONE TO AVOID COMPLICATIONS." 06-114r2: [298:16+15] 13.6 Specific names for standard intrinsic functions, table, After "ATAN" in the first column, insert "(X)". 06-175r2: [300:29] 13.7.2 ACHAR, Description of argument I, Replace description with "shall be of type integer or bits. If I is of type bits, it is interpreted as a nonnegative integer as described in 13.3.". [301:6] 13.7.2, Example, append "ACHAR(z'41') has the value 'A'.". 05-204r2: [301:10] 13.7.3 ACOS(X), Argument paragraph, after "1" insert ", or of type complex". 05-204r2: [301:13] 13.7.3 ACOS(X), Result Value paragraph, - delete ", expressed in radians". - change "It lies" to "If it is real it is expressed in radians and lies". - append to paragraph "If it is complex the real part is expressed in radians and lies in the range $0 \leq$ REAL(ACOS(X)) $\leq \pi$.". 05-204r2: [301:14+] Before 13.7.4 ADJUSTL(STRING) insert new section: "13.7.3a ACOSH (X) Description.Inverse hyperbolic cosine function. Class. Elemental function. Argument. X shall be of type real or complex. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation to the inverse hyperbolic cosine function of X. If the result is complex the imaginary part is expressed in radians and lies in the range $0 \leq$ AIMAG(ACOSH(X)) $\leq \pi$. Example. ACOSH(1.5430806) has the value 1.0 (approximately)." 05-204r2: [304:14] 13.7.12 ASIN(X), Argument paragraph, after "1" insert ", or of type complex". 05-204r2: [304:17] 13.7.12 ASIN(X), Result Value paragraph, - delete ", expressed in radians". - change "It lies" to "If it is real it is expressed in radians and lies". - append to paragraph "If it is complex the real part is expressed in radians and lies in the range $-\pi/2 \leq$ REAL(ASIN(X)) $\leq \pi/2$." 05-204r2: [304:18+] Before 13.7.13 ASSOCIATED insert new section: "13.7.12a ASINH (X) Description.Inverse hyperbolic sine function. Class. Elemental function. Argument. X shall be of type real or complex. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation to the inverse hyperbolic sine function of X. If the result is complex the imaginary part is expressed in radians and lies in the range $-\frac\pi2 \leq$ AIMAG(ASINH(X)) $\leq \frac\pi2$. Example. ASINH(1.1752012) has the value 1.0 (approximately). 06-114r2: [305:28] 13.7.14 ATAN(X), heading, After "ATAN(X)" add " or ATAN(Y,X)". 05-204r2: [305:31] 13.7.14 ATAN(X), Argument paragraph, After "real" insert "or complex". NOTE: This edit is superceded by the one to [305:31-34] from 06-114r2. 06-114r2: [305:31-34] 13.7.14, Argument, Result Characteristics, and Result Value paragraphs, Replace with "Arguments. Y shall be of type real. X If Y is present, X shall be of type real with the same kind type parameter as Y. If Y has the value zero, X shall not have the value zero. If Y is absent, X shall be of type real or complex. Result characteristics. Same as X. Result value. If Y is present, the result is the same as the result of ATAN2(Y,X). If Y is absent, the result has a value equal to a processor-dependent approximation to arctan(X) whose real part is expressed in radians and lies in the range $-\pi/2 \leq$ ATAN(X) $\leq \pi/2$. NOTE: This edit supercedes the one from 05-204r2. But if that paper is withdrawn, modify this edit as follows: The replacement text for argument X in the Argument paragraph becomes: "X shall be of type real. If Y is present, X shall have the same kind type parameter as Y. If Y has the value zero, X shall not have the value zero." and the replacement text for the Result Value paragraph becomes "Result value. If Y is present, the result is the same as the result of ATAN2(Y,X). If Y is absent, the result has a value equal to a processor-dependent approximation to arctan(X), expressed in radians, that lies in the range $-\pi/2 \leq$ ATAN(X) $\leq \pi/2$.". 05-204r2: [305:34] 13.7.14 ATAN(X), Result Value paragraph, - delete ", expressed in radians". - change "It lies" to "If it is real it is expressed in radians and lies". - append to paragraph "If it is complex the real part is expressed in radians and lies in the range $-\frac\pi2 \leq$ REAL(ATAN(X)) $\leq \frac\pi2$." NOTE: Superceded by the preceding edit. 05-204r2: [305:35+] Before 13.7.15 ATAN2 insert new section: "13.7.14a ATANH (X) Description.Inverse hyperbolic tangent function. Class. Elemental function. Argument. X shall be of type real or complex. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation to the inverse hyperbolic tangent function of X. If the result is complex the imaginary part is expressed in radians and lies in the range $-\frac\pi2 \leq$ AIMAG(ATANH(X)) $\leq \frac\pi2$. Example. ATANH(0.76159416) has the value 1.0 (approximately)." 05-268r3: [306:13+] After 13.7.15, insert new subclauses "13.7.15a BESSEL_J0 (X) Description. Bessel function of the first kind of order zero. Class. Elemental function. Argument. X shall be of type real. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Bessel function of the first kind of order zero of X. Example. BESSEL_J0(1.0) has the value 0.765 (approximately). 13.7.15b BESSEL_J1 (X) Description. Bessel function of the first kind of order one. Class. Elemental function. Argument. X shall be of type real. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Bessel function of the first kind of order one of X. Example. BESSEL_J1(1.0) has the value 0.440 (approximately). 13.7.15c BESSEL_JN (N,X) Description. Bessel function of the first kind of order N. Class. Elemental function. Arguments. N shall be of type integer and nonnegative. X shall be of type real. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Bessel function of the first kind of order N of X. Example. BESSEL_JN(2, 1.0) has the value 0.115 (approximately). 13.7.15d BESSEL_Y0 (X) Description. Bessel function of the second kind of order zero. Class. Elemental function. Argument. X shall be of type real. Its value shall be greater than zero. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Bessel function of the second kind of order zero of X. Example. BESSEL_Y0(1.0) has the value 0.088 (approximately). 13.7.15e BESSEL_Y1 (X) Description. Bessel function of the second kind of order one. Class. Elemental function. Argument. X shall be of type real. Its value shall be greater than zero. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Bessel function of the second kind of order one of X. Example. BESSEL_Y1(1.0) has the value -0.781 (approximately). 13.7.15f BESSEL_YN (N,X) Description. Bessel function of the second kind of order N. Class. Elemental function. Arguments. N shall be of type integer and nonnegative. X shall be of type real. Its value shall be greater than zero. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Bessel function of the second kind of order N of X. Example. BESSEL_YN(2, 1.0) has the value -1.651 (approximately)." 06-175: [306:14-] Immediately before 13.7.16 BIT_SIZE(I), and after the BESSEL_YN edit above, insert new subclauses alphabetically "13.7.15f BITS (A [, KIND]) <> Convert to bits type. <> Elemental function. <> A shall be of type integer, real, complex, logical, or bits. KIND (optional) shall be a scalar integer initialization expression. <> Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is BITS_KIND(A).". NOTE FROM THE EDITOR: I CHANGED THE DEFAULT RESULT FROM "default bits". Leaving it at "default bits" would have reintroduced the same bug we already have in the CMPLX intrinsic, which in CMPLX(X) fails to convert double precision real to double precision complex unless the user writes the tedious and easily forgotten KIND argument, viz CMPLX(X,KIND=KIND(X)). We have already seen that this has caused many problems in user programs. Similarly, to get the bits of X, we should just have BITS(X) not require the user to write the silly BITS(X,BITS_KIND(X)). Having the right default makes it easier to make the program portable between machines with default real being 32 and 64 bits. If the user *REALLY WANTS* to reduce it to default bits, he can write BITS(X,BIT_KIND(0)) or BITS(X,NUMERIC_STORAGE_SIZE). Or if he wants to chop it off at 32, BITS(X,32). "<> If A is of type bits and the kind type parameter of A is the same as that of the result, the result value is the value of A. If A is of type bits with a smaller kind type parameter value than that of the result, the rightmost KIND(A) bits of the result value are the same as those of A and the remaining bits of the result are 0. If A is of type bits with a larger kind type parameter value than that of the result, the result value consists of the rightmost KIND(result) bits of A. If A is not of type bits and BITS_KIND(A) is greater than or equal to the kind type parameter of the result, the result value consists of the rightmost KIND(result) bits of the internal representation of A. If A is not of type bits and BITS_KIND(A) is less than or equal to the kind type parameter of the result, the rightmost bits of the result are those of the internal representation of A and the remaining bits of the result are 0. <> BITS(z'abcd',32) has the value z'0000abcd'. BITS(-1) has the value z'ffffffff' for an implementation where the default integer representation is 32-bit two's-complement. BITS(.true.,5) has the value b'00001' for an implementation that represents the logical value true by setting the low order bit of the internal value and clearing the other bits. BITS(X) has the value z'7f800000' if the value of X is an IEEE 32-bit positive infinity and default bits kind is 32. 13.7.15g BITS_KIND (X [, KIND]) <> Return bits kind compatible with the argument. <> Inquiry function. <> X shall be of type bits, integer, real, complex, or logical. KIND (optional) shall be a scalar integer initialization expression. <> Scalar integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. J3 TECHNICAL NOTE It is good that people are thinking about bitstrings greater than 512MB, but since intrinsic kind type parameters are of default integer type, there is a slight problem here. Better make the kind type parameter for bits type processor-dependent or something. ***AND*** change the KIND intrinsic to have a KIND argument (bleurgh). Alternatively, remove the useless KIND argument from this intrinsic since it will indeed be useless. <> If X is of type bits, the result value is KIND(X). If X is of type default integer, default real, or default logical, the result value is NUMERIC_STORAGE_SIZE (13.8.2.7). If X is of type double precision or default complex, the result is 2*NUMERIC_STORAGE_SIZE. If X is of type complex with the same kind type parameter as that of double precision, the result value is 4*NUMERIC_STORAGE_SIZE. If X is of type non-default integer, the result value is BIT_SIZE(X). If X is of a non-default logical or non-default non-integer numeric type, the result value is the number of bits of storage used by the processor to represent scalar objects of that type and kind. <> The value of BITS_KIND(0) is 32 if the value of NUMERIC_STORAGE_SIZE is 32.". NOTE FROM THE EDITOR: Since BITS are now required to support all processor- defined kinds of integer et al, this doesn't need an error return. (Yet.) 06-175r2: [306:14-21] 13.7.16 BIT_SIZE, replace subclause with "13.7.16 BIT_SIZE(I [, KIND]) <> Returns the number of bits. <> Inquiry function. <> I shall be of type integer or bits. It may be a scalar or an array. KIND (optional) shall be a scalar integer initialization expression. <> Scalar integer. If KIND is present, the kind type parameter is that specified by the value of KIND. If KIND is not present and I is of type integer the result is a scalar integer with the same kind type parameter as I. If KIND is not present and I is of type bits, the result is a scalar of type default integer. <> If I is of type integer, the result has the value of the number of bits of the model integer defined for bit manipulation contexts in 13.3. If I is of type bits, the result value is KIND(I). <> BIT_SIZE(1) has the value 32 if of the model is 32. BIT_SIZE(z'ffff') has the value 16.". NOTE FROM THE EDITOR: This seems like a lot of change for little purpose (since BIT_SIZE(bits)==KIND(bits)). The purpose is apparently that BIT_SIZE is used widely in the definition of bit operations and it's simpler to extend the intrinsic than to change the wording. 06-175r2: [306:23] 13.7.17 BTEST, Description paragraph, replace with "Tests a bit of an integer or bits value." [306:26] 13.7.17, Arguments paragraph, Change the description of the I argument to: "shall be of type integer or bits." [306:32] 13.7.17, Examples paragraph, after the first example, insert "BTEST(b'01000',3) has the value true.". 06-175r2: [307:17] 13.7.19 CHAR, Arguments paragraph, Change the description of the argument I to "shall be of type integer or bits. If I is of type bits, it is interpreted as a non-negative integer as described in 13.3. The value of I shall be in the range 0 <= I <= -1, where is the number of characters in the collating sequence associated with the specified kind type parameter." [307:26] Example paragraph, Change paragraph title to "Examples", Append new sentence "CHAR(z'41') has the value 'A' on a processor using the ASCII collating sequence.". 06-175r2: [307:31] 13.7.20 CMPLX, Arguments paragraph, X argument, Change "or complex, or a " to "complex, or bits". [308:1] Y argument, Change "integer or real, or a " to "integer, real, or bits". 05-204r2: [309:7] 13.7.24 COSH(X), Argument paragraph, After "real" insert "or complex". 05-204r2: [309:9] 13.7.24 COSH(X), Result Value paragraph, append "If X is of type complex its imaginary part is regarded as a value in radians." 06-174r3: (NOTE: following this are some bits edits which modify this edit.) [309:33-] Immediately before 13.7.26 CPU_TIME (TIME), insert new subclauses "13.7.25a CO_ALL(MASK, RESULT [,TEAM]) <> Determine whether all values are true on a team of images. <> Collective subroutine. <> MASK shall be a co-array of type logical. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of type logical and have the same shape as MASK. It is an INTENT(OUT) argument. If it is scalar, it is assigned the value true if the value of MASK is true on all the images of the team, and the value false otherwise. If it is an array, each element is assigned the value true if all corresponding elements of MASK are true on all the images of the team, and the value false otherwise. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_ALL is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and MASK has the values (/.TRUE.,.FALSE.,.TRUE./) and (/.TRUE.,.TRUE.,.TRUE./) on the two images, executing CALL CO_ALL(MASK,RESULT) assigns RESULT the value [true, false, true]. 13.7.25b CO_ANY(MASK, RESULT [,TEAM]) <> Determine whether any value is true on a team of images. <> Collective subroutine. <> MASK shall be a co-array of type logical. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of type logical and have the same shape as MASK. It is an INTENT(OUT) argument. If it is scalar it is assigned the value true if any value of MASK is true on any image of the team, and false otherwise. If it is an array, each element is assigned the value true if any of the corresponding elements of MASK are true on any image of the team, and false otherwise. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_ANY is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and MASK has the values (/.TRUE.,.FALSE.,. FALSE./) and (/.TRUE.,.TRUE.,.FALSE./) on the two images, executing CALL CO_ANY(MASK,RESULT) assigns RESULT the value [true, true, false]. 13.7.25c CO_COUNT(MASK, RESULT [,TEAM]) <> Count the numbers of true elements on a team of images. <> Collective subroutine. <> MASK shall be a co-array of type logical. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of type integer and have the same shape as MASK. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to the number of images of the team for which MASK has the value true. If it is an array, each element is assigned a value equal to the number of corresponding elements of MASK on the images of the team that have the value true. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_COUNT is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and MASK has the values (/.TRUE.,.FALSE.,. FALSE./) and (/.TRUE.,.TRUE.,.FALSE./) on the two images, executing CALL CO_COUNT(MASK,RESULT) gives RESULT the value [2, 1, 0]. 13.7.25d CO_LBOUND (CO_ARRAY [, DIM, KIND]) <> Returns all the lower co-bounds or a specified lower co-bound of a co-array. <> Inquiry function. <> CO_ARRAY shall be a co-array of any type. It may be a scalar or an array. If it is allocatable it shall be allocated. DIM (optional) shall be scalar and of type integer with a value in the range 1 <= DIM <= n, where n is the co-rank of CO_ARRAY. The corresponding actual argument shall not be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. The result is scalar if DIM is present; otherwise, the result is an array of rank one and size n, where n is the co-rank of CO_ARRAY. <> : CO_LBOUND (CO_ARRAY, DIM) has a value equal to the lower co-bound for co-subscript DIM of CO_ARRAY. : CO_LBOUND (CO_ARRAY) has a value whose ith component is equal to CO_LBOUND (CO_ARRAY, i), for i = 1, 2,..., n, where n is the co-rank of CO_ARRAY. < If A is allocated by the statement ALLOCATE ( A [2:3, 7:*] ) then CO_LBOUND (A) is [2, 7] and CO_LBOUND (A, DIM=2) is 7. 13.7.25e CO_MAXLOC(CO_ARRAY, RESULT [,TEAM]) <> Image indices of maximum values of the elements on a team of images. <> Collective subroutine. <> CO_ARRAY shall be a co-array of type integer, real, or character. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of type integer and have the same shape as CO_ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to the smallest image index of a maximum value of CO_ARRAY on the images of the team. If it is an array, each element of RESULT is assigned a value equal to the smallest image index of a maximum value of all the corresponding elements of CO_ARRAY on the images of the team. If CO_ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for characters with the kind type parameter of the argument is applied. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_MAXLOC is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and CO_ARRAY has the values (/1,5,6/) and (/4,1,6/) on the two images, executing CALL CO_MAXLOC(CO_ARRAY,RESULT) assigns RESULT the value (/2,1,1/). 13.7.25f CO_MAXVAL(CO_ARRAY, RESULT [,TEAM]) <> Maximum values of the elements on a team of images. <> Collective subroutine. <> CO_ARRAY shall be a co-array of type integer, real, or character. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of the same type and type parameters as CO_ARRAY, and shall have the same shape as CO_ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to the maximum value of CO_ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to the maximum value of all the corresponding elements of CO_ARRAY on all the images of the team. If CO_ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for characters with the kind type parameter of the argument is applied. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_MAXVAL is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and CO_ARRAY has the values (/1,5,3/) and (/4,1,6/) on the two images, executing CALL CO_MAXVAL(CO_ARRAY,RESULT) assigns RESULT the value (/4,5,6/). 13.7.25g CO_MINLOC(CO_ARRAY, RESULT [,TEAM]) <> Image indices of minimum values of the elements on a team of images. <> Collective subroutine. <> CO_ARRAY shall a co-array of type integer, real, or character. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of type integer and have the same shape as CO_ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to the smallest image index of a minimum value of CO_ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to the smallest image index of a minimum value of all the corresponding elements of CO_ARRAY on the images of the team. If CO_ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for characters with the kind type parameter of the argument is applied. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_MINLOC is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and CO_ARRAY has the values (/1,5,6/) and (/4,1,6/) on the two images, executing CALL CO_MINLOC(ARRAY,RESULT) assigns RESULT the value (/1,2,1/). 13.7.25h CO_MINVAL(CO_ARRAY, RESULT [,TEAM]) <> Minimum values of the elements on a team of images. <> Collective subroutine. <> CO_ARRAY shall be a co-array of type integer, real, or character. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of the same type and type parameters as CO_ARRAY, and shall have the same shape as CO_ARRAY. It is an INTENT(OUT) argument. If it is scalar it is assigned a value equal to the minimum value of CO_ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to the minimum value of all the corresponding elements of CO_ARRAY on all the images of the team. If CO_ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for characters with the kind type parameter of the argument is applied. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_MINVAL is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and CO_ARRAY has the values (/1,5,3/) and (/4,1,6/) on the two images, executing CALL CO_MINVAL(CO_ARRAY,RESULT) gives RESULT the value (/1,1,3/). 13.7.25i CO_PRODUCT(CO_ARRAY, RESULT [,TEAM]) <> Products of elements on a team of images. <> Collective subroutine. <> CO_ARRAY shall be a co-array of type integer, real, or complex. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of the same type and kind type parameters as CO_ARRAY, and shall have the same shape as CO_ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to a processor-dependent and image-dependent approximation to the product of the values of CO_ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to a processor-dependent and image-dependent approximation to the product of all the corresponding elements of CO_ARRAY on the images of the team. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_PRODUCT is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and CO_ARRAY has the values (/1,5,3/) and (/4,1,6/) on the two images, executing CALL CO_PRODUCT(CO_ARRAY,RESULT) gives RESULT the value (/4,5,18/). 13.7.25j CO_SUM(CO_ARRAY, RESULT [,TEAM]) <> Sums of elements on a team of images. <> Collective subroutine. <> CO_ARRAY shall be a co-array of type integer, real, or complex. It may be a scalar or an array. It is an INTENT(IN) argument. RESULT shall be of the same type and kind type parameters as CO_ARRAY, and shall have the same shape as CO_ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to a processor-dependent and image-dependent approximation to the sum of the values of CO_ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to a processor-dependent and image-dependent approximation to the sum of all the corresponding elements of CO_ARRAY on the images of the team. TEAM (optional) shall be a scalar of type IMAGE_TEAM (13.8.2). It is an INTENT(IN) argument that specifies the team for which CO_SUM is performed. If TEAM is not present, the team consists of all images. <> If NUM_IMAGES() has the value 2 and CO_ARRAY has the values (/1,5,3/) and (/4,1,6/) on the two images, executing CALL CO_SUM(CO_ARRAY,RESULT) gives RESULT the value (/5,6,9/). 13.7.25k CO_UBOUND (CO_ARRAY [, DIM, KIND]) <> Returns all the upper co-bounds or a specified upper co-bound of a co-array of co-rank greater than one. <> Inquiry function. <> CO_ARRAY shall be a co-array of any type and of co-rank greater than one. It may be a scalar or an array. If it is allocatable it shall be allocated. DIM (optional) shall be scalar and of type integer with a value in the range 1 <= DIM <= n-1, where n is the co-rank of CO_ARRAY. The corresponding actual argument shall not be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. The result is scalar if DIM is present; otherwise, the result is an array of rank one and size n-1, where n is the co-rank of CO_ARRAY. <> : CO_UBOUND (CO_ARRAY, DIM) has a value equal to the upper co-bound for co-subscript DIM of CO_ARRAY. : CO_UBOUND (CO_ARRAY) has a value whose ith component is equal to CO_UBOUND (CO_ARRAY, i), for i = 1, 2,..., n-1, where n is the co-rank of CO_ARRAY. < If A is allocated by the statement ALLOCATE ( A [2:3, 0:7, *] ) then CO_UBOUND (A) is [3, 7] and CO_UBOUND (A, DIM=2) is 7.". 06-175r2: [In the above edit] 13.7.25d CO_MAXLOC, Arguments paragraph, ARRAY argument, 13.7.25e CO_MAXVAL, Arguments paragraph, ARRAY argument, 13.7.25f CO_MINLOC, Arguments paragraph, ARRAY argument, 13.7.25g CO_MINVAL, Arguments paragraph, ARRAY argument, After "of type integer, real" insert ", bits" in each place. 06-175r2: [312:21] 13.7.29 DBLE, Arguments paragraph, A argument, Change "or complex or a " to "complex, or bits". 06-175r2: [314:12-] Immediately before 13.7.34 EOSHIFT, insert new subclauses "13.7.33a DSHIFTL (I, J, SHIFT) <> Performs a combined left shift. <> Elemental function. <> I shall be of type integer or bits. J shall be of the same type and kind as I. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The result has the value IOR(SHIFTL(I,SHIFT), SHIFTR(J, BIT_SIZE(J)-SHIFT)). DSHIFTL(I,I,SHIFT) has the same result value as ISHFTC(I,SHIFT). <> DSHIFTL(z'01234567', z'89abcdef', 8) has the value z'23456789'. 13.7.33b DSHIFTR (I, J, SHIFT) <> Performs a combined right shift. <> Elemental function. <> I shall be of type integer or bits. J shall be of the same type and kind as I. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The result has the value IOR(SHIFTL(I, BIT_SIZE(I)-SHIFT), SHIFTR(J, SHIFT)). DSHIFTR(I,I,SHIFT) has the same result value as ISHFTC(I,-SHIFT). <> DSHIFTR(z'01234567', z'89abcdef', 8) has the value z'6789abcd'. DSHIFTR(B'111',B'000',2) has the value B'110'.". 05-268r3: [315:24+] After 13.7.35 EPSILON(X), insert new subclauses: "13.7.35a ERF (X) Description. Error function. Class. Elemental function. Argument. X shall be of type real. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the error function of X, 2 divided by sqrt(pi) times the integral from 0 to x of exp( -t*t) dt. Example. ERF(1.0) has the value 0.843 (approximately). 13.7.35b ERFC (X) Description. Complementary error function. Class. Elemental function. Argument. X shall be of type real. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the complementary error function (that is, 1 - ERF(X)) of X. Example. ERFC(1.0) has the value 0.157 (approximately)." 05-264r3: [315:24+] After 13.7.3 EPSILON (X), insert new subclause "13.7.35c ERFC_SCALED (X) Description. Exponentially-scaled complementary error function. Class. Elemental function. Argument. X shall be of type real. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation to the exponentially-scaled complementary error function, $\exp(X^2) \frac2{\sqrt\pi} \int_X^\infty \exp(-t^2) \text{d}t$. Example. ERFC_SCALED(20.0) has the value 0.02817434874 (approximately). Note 13.8a The complementary error function is asymptotic to $\exp(-X^2)/(X\sqrt\pi)$. As such it underflows for $X > \approx 9$ when using single-precision IEEE arithmetic. The exponentially-scaled complementary error function is asymptotic to $1/(X \sqrt\pi)$. As such it does not underflow until $X > \text{HUGE}(X)/\sqrt\pi$.". 05-240r4: [315:24+] 13.7 Specification of the standard intrinsic procedures, before 13.7.36 EXP(X), insert new subclause "13.7.35c EXECUTE_COMMAND_LINE(COMMAND [, WAIT, EXITSTAT, CMDSTAT, CMDMSG ]) Description. Execute the command line specified by the string COMMAND. If the processor supports command line execution, it shall support synchronous and may support asynchronous execution of the command line. Class. Subroutine. Arguments. COMMAND shall be of type default character and shall be a scalar. It is an INTENT(IN) argument. Its value is the command line to be executed. The interpretation is processor-dependent. WAIT (optional) shall be of type default logical and shall be a scalar. It is an INTENT(IN) argument. If WAIT is present with the value false, and the processor supports asynchronous execution of the command, the command is executed asynchronously; otherwise it is executed synchronously. EXITSTAT (optional) shall be of type default integer and shall be a scalar. It is an INTENT(INOUT) argument. If the command is executed synchronously, it is assigned the value of the processor-dependent exit status. Otherwise, the value of EXITSTAT is unchanged. CMDSTAT (optional) shall be of type default integer and shall be a scalar. It is an INTENT(OUT) argument. It is assigned the value -1 if the processor does not support command line execution, a processor-dependent positive value if an error condition occurs, or the value -2 if no error condition occurs but WAIT is present with the value false and the processor does not support asynchronous execution. Otherwise it is assigned the value 0. CMDMSG (optional) shall be of type default character and shall be a scalar. It is an INTENT(INOUT) argument. If an error condition occurs, it is assigned a processor-dependent explanatory message. Otherwise, it is unchanged. When the command is executed synchronously, EXECUTE_COMMAND_LINE returns after the command line has completed execution. Otherwise, EXECUTE_COMMAND_LINE returns without waiting. If an error condition occurs and CMDSTAT is not present, execution of the program is terminated." 06-181r1: [316:23-] Immediately before 13.9.39 FLOOR (A [, KIND]), insert new subclause "13.7.38A FINDLOC (ARRAY, VALUE, DIM, [,MASK, KIND, BACK]) or FINDLOC (ARRAY, VALUE, [,MASK, KIND, BACK]) Description. Determine the location of the first element of ARRAY identified by MASK along dimension DIM having a value equal to VALUE. Class. Transformational function. Arguments. ARRAY shall be of intrinsic type. It shall be an array." NOTE TO THE EDITOR: Other intrinsics are inconsistent, some say "not be scalar", others say "be array". Please make consistent globally] "VALUE shall be in type conformance with ARRAY, as specified in Table 7.8. DIM shall be scalar and of type integer with a value in the range 1 <= DIM <= n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. KIND (optional) shall be a scalar integer initialization expression. BACK (optional) shall be scalar and of type logical." NOTE TO THE EDITOR: type set the d1, ei, sDIM+1, etc. as in MAXLOC "Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise the kind type parameter is that of default integer type. If DIM is absent, the result is an array of rank one and of size equal to the rank of ARRAY; otherwise, the result is of rank n - 1 and shape (d1, d2, ..., dDIM-1 , dDIM+1, ..., dn), where (d1, d2, ..., dn) is the shape of ARRAY. Result Value. Case (i): The result of FINDLOC (ARRAY, VALUE) is a rank-one array whose element values are the values of the subscripts of an element of ARRAY whose value matches VALUE. The ith subscript returned lies in the range 1 to ei, where ei is the extent of the ith dimension of ARRAY. If no elements match VALUE or ARRAY has size zero, all elements of the result are zero. Case (ii): The result of FINDLOC (ARRAY, VALUE, MASK = MASK) is a rank-one array whose element values are the values of the subscripts of an element of ARRAY, corresponding to a true element of MASK, whose value matches VALUE. The ith subscript returned lies in the range 1 to ei, where ei is the extent of the ith dimension of ARRAY. If no elements match VALUE, ARRAY has size zero, or every element of MASK has the value false, all elements of the result are zero. Case (iii): If ARRAY has rank one, FINDLOC (ARRAY, VALUE, DIM=DIM, [, MASK = MASK]) is a scalar whose value is equal to that of the first element of FINDLOC (ARRAY ,VALUE [, MASK = MASK]). Otherwise, the value of element (s1, s2, ..., sDIM-1 , sDIM+1, ..., sn ) of the result is equal to FINDLOC (ARRAY (s1, s2, ..., sDIM-1 , :, sDIM+1, ..., sn), VALUE, DIM=1, [, MASK = MASK (s1, s2, ..., sDIM-1 , :, sDIM+1, ..., sn) ] ). If both ARRAY and VALUE are of type logical, the comparison is performed as array-element .EQV. VALUE; otherwise, the comparison is performed as array-element == VALUE. If the value of the comparison is true, array-element matches VALUE. If only one element matches VALUE, that element's subscripts are returned. Otherwise, if more than one element matches VALUE and BACK is absent or present with the value false, the element whose subscripts are returned is the first such element, taken in array element order. If BACK is present with the value true, the element whose subscripts are returned is the last such element, taken in array element order. Examples. Case (i): The value of FINDLOC ((/ 2, 6, 4, 6 /), 6) is [2], and the value of FINDLOC ((/ 2, 6, 4, 6 /), 6, BACK= .TRUE.) is [4]. 0 -5 7 7 Case (ii): If A has the value 3 4 -1 2 1 5 6 7 T T F T and M has the value T T F T T T F T FINDLOC (A, 7, MASK = M) has the value [1,4] and FINDLOC( A, 7, MASK =A, BACK = .TRUE.) has the value [3,4]. Note that this is independent of the declared lower bounds for A. case (iii): The value of FINDLOC([2,6,4],VALUE=6, DIM=1) is 2. If B has the value 1 2 -9 2 2 6 FINDLOC( B, 2, DIM=1) has the value [2,1,0] and FINDLOC(B,2,DIM=2) has the value [2,1]. Note that this is true even if B has a declared lower bound other than 1." NOTE FROM THE EDITOR: I feel somewhat dissatisfied with the text describing FINDLOC/MAXLOC/MINLOC; this is nothing new, but the "subscripts" being returned are not in fact the actual subscripts (as is pointed out in the examples). I don't have any better words, though perhaps saying that it returns "1-based subscripts" would remove my doubts. 06-174r3: [317:2-] Immediately before 13.7.40 FRACTION(X), insert new subclause "13.7.39a FORM_TEAM(TEAM, IMAGES) <> Form a team of images. <> Collective subroutine. J3 TECHNICAL NOTE I don't see why FORM_TEAM needs synchronisation - that seems completely unnecessary (it has no co-array argument, no need for communication - its actual arguments are all simple local variables). <> TEAM shall be a scalar of the derived type IMAGE_TEAM that is defined in the intrinsic module ISO_FORTRAN_ENV (13.8.2). It is an INTENT(OUT) argument. IMAGES shall be of rank one and type integer. It is an INTENT(IN) argument that specifies the image indices of the team members, and shall have the same value on all images of the team. All the elements shall have values in the range 1, ..., NUM_IMAGES() and there shall be no repeated values. It shall not have size zero. <> The following splits images into two equal groups and implicitly synchronizes each of the teams if there are two or more images. If there is only one image, that image becomes the only team member. USE, INTRINSIC :: ISO_FORTRAN_ENV INTEGER :: I TYPE(IMAGE_TEAM) :: TEAM IF (THIS_IMAGE()<=NUM_IMAGES()/2) THEN CALL FORM_TEAM(TEAM,[(I,I=1,NUM_IMAGES()/2)]) ELSE CALL FORM_TEAM(TEAM,[(I,I=NUM_IMAGES()/2+1,NUM_IMAGES())]) END IF". 05-268r3: [317:10+] After 13.7.40 FRACTION(X), insert subclause "13.7.40a GAMMA (X) Description. Gamma function. Class. Elemental function. Argument. X shall be of type real. Its value shall not be a negative integer or zero. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the gamma function of X, $\Gamma(X) = ...$ the integral from 0 to infinity of exp( -t) t**( X - 1) dt. Example. GAMMA(1.0) has the value 1.000 (approximately)." 06-175r2: [319:11-12] 13.7.44 HUGE, Description paragraph, Replace "number" with "value" and "numbers" with "values". NOTE FROM THE EDITOR: WHAT IS THIS MEANT TO ACHIEVE? THE MODEL IN 13.3 DEFINES BITS AS NUMBERS ALREADY. [319:14] Argument paragraph, Replace "of type integer or real" with "of type integer, real, or bits". [319:18] Result Value paragraph, append new sentence "If X is of type bits, the result value has all of its bits set to 1.". 05-268r3: [319:20+] After 13.7.44 HUGE(X), insert subclause "13.7.44a HYPOT (X,Y) Description. Euclidean distance function Class. Elemental function. Arguments. X shall be of type real. Y shall be of type real with the same kind type parameter as X. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the Euclidean distance, sqrt( X**2 + Y**2 ), without undue overflow or underflow. Example. HYPOT(2.0, 1.0) has the value 2.236 (approximately)." 06-175r2: [320:15-] Immediately before 13.7.46 IAND, insert new subclause "13.7.45a IALL (ARRAY ,DIM [, MASK]) or IALL (ARRAY, [MASK] ) <> Bitwise AND of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. <> Transformational function. <> ARRAY shall be of type integer or bits. It shall not be scalar. DIM (optional) shall be a scalar of type integer with a value in the range 1 <= DIM <= where is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. <> The result is of the same type and kind type parameter as ARRAY. It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of ARRAY. <> : The result of IALL(ARRAY) has a value equal to the bitwise AND of all the elements of ARRAY. If ARRAY has size zero the result value is equal to NOT(INT(0,KIND(ARRAY))) if ARRAY is of type integer, and NOT(BITS(b'0',KIND(ARRAY))) otherwise. : The result of IALL(ARRAY, MASK=MASK) has a value equal to IALL(PACK(ARRAY, MASK))." NOTE FROM THE EDITOR: CUTE, BUT SHOULD WE NOT WORD OUR REDUCTIONS CONSISTENTLY? NOTE TO THE EDITOR: Existing reductions are inconsistent! ": The result of IALL(ARRAY, DIM=DIM [,MASK=MASK]) has a value equal to that of IALL(ARRAY, [, MASK=MASK] if ARRAY has rank one. Otherwise, the value of element () of the result is equal to IALL(ARRAY() [,MASK = MASK(s_1, s_2, ..., s_{DIM-1},:, s_{DIM+1}, ..., s_n>]) <> IALL( [b'1110', b'1101', b'1011'] ) has the value b'1000'. IALL( [b'1110', b'1101', b'1011'], MASK=[.true.,.false.,.true]) has the value b'1010'. IALL( [14, 13, 11] ) has the value 8. IALL( [14, 13, 11], MASK=[.true.,.false.,.true]) has the value 10.". 06-175r2: [320:19] 13.7.46 IAND, Arguments paragraph, I argument, After "integer" insert "or bits". [320:20] J argument, Change "with ... as I" to "or bits. BITS_KIND(I) shall be equal to BITS_KIND(J).". [320:21] Result Characteristics paragraph, replace contents with "If I and J have the same type, the result characteristics are those of I. Otherwise, the result characteristics are those of the argument with integer type." [320:25] Example paragraph, replace "Example" with "Examples" and append "IAND(z'12345678', z'0000ffff') has the value z'00005678'.". 06-175r2: [320:25+] Immediately before 13.7.47 IBCLR, insert new subclause "13.7.46a IANY (ARRAY ,DIM [, MASK]) or IANY (ARRAY, [MASK] ) <> Bitwise OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. <> Transformational function. <> ARRAY shall be of type integer or bits. It shall not be scalar. DIM (optional) shall be a scalar and of type integer with a value in the range 1 <= DIM <= where is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. <> The result is of the same type and kind type parameter as ARRAY. It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of ARRAY. <> : The result of IANY(ARRAY) is the bitwise OR of all the elements of ARRAY. If ARRAY has size zero the result value is equal to zero if ARRAY is of type integer, and BITS(b'0',KIND(ARRAY)) otherwise. : The result of IANY(ARRAY, MASK=MASK) has a value equal to IANY(PACK(ARRAY, MASK)). : The result of IANY(ARRAY, DIM=DIM [,MASK=MASK]) has a value equal to that of IANY(ARRAY, [, MASK=MASK] if ARRAY has rank one. Otherwise, the value of element () of the result is equal to IANY(ARRAY() [,MASK = MASK(s_1, s_2, ..., s_{DIM-1},:, s_{DIM+1}, ..., s_n>]) <> IANY( [b'1110', b'1101', b'1000'] ) has the value b'1111'. IANY( [b'1110', b'1101', b'1000'], MASK=[.true.,.false.,.true]) has the value b'1110'. IANY( [14, 13, 8] ) has the value 15. IANY( [14, 13, 8], MASK=[.true.,.false.,.true]) has the value 14.". 06-175r2: [320:30] 13.7.47 IBCLR, Argument paragraph, I argument, After "of type integer" insert "or bits". [321:6] Examples paragraph, append new sentence "IBCLR(b'11111',3) has the value b'10111'.". 06-175r2: [321:11] 13.7.48 BITS, Argument paragraph, I argument After "of type integer" insert "or bits". [321:18] Example paragraph, pluralise title and append new sentence "IBITS(z'abcd',4,8) has the value z'00bc'.". 06-175r2: [321:23] 13.7.49 IBSET, Arguments paragraph, I argument, After "of type integer" insert "or bits". [321:29] Examples paragraph, append new sentence "IBSET(b'00000',3) has the value b'01000'.". 06-175r2: [322:17] 13.7.51 IEOR, Arguments paragraph, I argument, After "of type integer" insert "or bits". [322:18] J argument, Change "with ... as I" to "or bits. BITS_KIND(I) shall be equal to BITS_KIND(J).". [322:19] Results Characteristics paragraph, replace contents with "If I and J have the same type, the result characteristics are those of I. Otherwise, the result characteristics are those of the argument with integer type." [322:23] Example paragraph, pluralise title and append new sentence "IEOR(z'12340000', z'1234ffff') has the value z'0000ffff'.". 06-174r3: [322:24-] Immediately before 13.7.52 INDEX, insert new subclause "13.7.51a IMAGE_INDEX(CO_ARRAY, SUB) <> Returns the index of the image corresponding to the co-subscripts SUB for CO_ARRAY. <> Inquiry function. <> CO_ARRAY shall be a co-array of any type. SUB shall be a rank-one array of size equal to the co-rank of CO_ARRAY and shall be of type integer. <> Default integer scalar. <> If the value of SUB is a valid sequence of co-subscripts for CO_ARRAY, the result is the index of the corresponding image. Otherwise, the result is zero." NOTE FROM THE EDITOR: After consultation with subgroup, picked zero for the failure indication (since it needed to do bounds checking anyway). "<> If A is declared A[0:*], IMAGE_INDEX(A,(/0/)) has the value 1. NOTE 13.16a For an example of a module implementing a function similar to the intrinsic THIS_IMAGE, see subclause \ref{DC:Module for THIS_IMAGE and IMAGE_INDEX}. [end NOTE]". 06-175r2: [323:21] 13.7.53 INT, Arguments paragraph, A argument, Replace "or complex, or a " with "complex, or bits", [323:31-33] Result Value paragraph, replace contents of case (iv) with "If A is of type bits, the result value is that specified by the model in 13.3 for interpreting the bits as an integer.". NOTE FROM THE EDITOR: The paper had a circular definition here. I have replaced it with (the extension to bits of) the F2003 defn for boz literals. NOTE TO THE EDITOR: Still defective, try something like "If A is of type bits, the result value is such that BITS(INT(A,KIND))==BITS(A,BITS_KIND(INT(0,KIND)))." Ugh. Maybe add "If the value specified by the model in 13.3 for interpreting the bits as an integer is a valid value for the result, it has that value." 06-175r2: [324:1] 13.7.54 IOR, Arguments paragraph, I argument After "of type integer" insert "or bits", [324:2] J argument Change "with ... as I" to "or bits. BITS_KIND(I) shall be equal to BITS_KIND(J).". [324:3] Results Characteristics paragraph, replace contents with "If I and J have the same type, the result characteristics are those of I. Otherwise, the result characteristics are those of the argument with integer type." [324:7] Example paragraph, pluralise title and append new sentence "IOR(z'12345678', z'0000ffff') has the value z'1234ffff'.". 06-175r2: [324:8-] Immediately before 13.7.55 ISHFT, insert new subclause "13.7.54a IPARITY (ARRAY ,DIM [, MASK]) or IPARITY (ARRAY, [MASK] ) <> Bitwise exclusive OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. <> Transformational function. <> ARRAY shall be of type integer or bits. It shall not be scalar. DIM (optional) shall be a scalar and of type integer with a value in the range 1 <= DIM <= where is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. <> The result is of the same type and kind type parameter as ARRAY. It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of ARRAY. <> : The result of IPARITY(ARRAY) is the bitwise exclusive OR of all the elements of ARRAY. If ARRAY has size zero the result value is equal to zero if ARRAY is of type integer, and BITS(b'0',KIND(ARRAY)) otherwise. : The result of IPARITY(ARRAY, MASK=MASK) has a value equal to IPARITY(PACK(ARRAY, MASK)). : The result of IPARITY(ARRAY, DIM=DIM [,MASK=MASK]) has a value equal to that of IPARITY(ARRAY, [, MASK=MASK] if ARRAY has rank one. Otherwise, the value of element () of the result is equal to IPARITY(ARRAY() [,MASK = MASK(s_1, s_2, ..., s_{DIM-1},:, s_{DIM+1}, ..., s_n>]) <> IPARITY( [b'1110', b'1101', b'1000'] ) has the value b'1011'. IPARITY( [b'1110', b'1101', b'1000'], MASK=[.true.,.false.,.true]) has the value b'0110'. IPARITY( [14, 13, 8] ) has the value 11. IPARITY( [14, 13, 8], MASK=[.true.,.false.,.true]) has the value 6.". 06-175r2: [324:12] 13.7.55 ISHFT, Arguments paragraph, I argument, After "of type integer" insert "or bits", [324:20] Example paragraph, pluralise title and append new sentence "ISHFT (b'00000011',1) has the value b'00000110'.". 06-175r2: [324:25] 13.7.56 ISHFTC, Arguments paragraph, I argument, After "of type integer" insert "or bits", [325:7] Example paragraph, pluralize title and append new sentence "ISHFTC (z'abcd',4,8) has the value z'abdc'.". 05-273r3: [325:7+] Immediately before 13.7.57 IS_IOSTAT_END(I), insert new subclause "13.7.56a IS_CONTIGUOUS(A) Description. Determine whether an object is contiguous (5.1.2.4a). Class. Inquiry function. Argument. A may be of any type. It shall be an assumed-shape array or an array pointer. If it is a pointer it shall be associated. Result Characteristics. Default logical scalar. Result Value. The result has the value true if A is contiguous, and false otherwise.". 06-175r2: [326:17-] Immediately before 13.7.61 LEN, insert new subclause "13.7.60a LEADZ (I [,KIND]) <> Count the number of leading zero bits. <> Elemental function. <> I shall be of type integer or bits. KIND (optional) shall be a scalar integer initialization expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. <> If all of the bits of I are zero, the result value is BIT_SIZE(I). Otherwise, the result value is BIT_SIZE(I)-1 minus the position of the leftmost 1 bit in I, where the rightmost bit position is 0. The model for the interpretation of an integer value as a sequence of bits is in 13.3. <> LEADZ(b'001101000') has the value 2. LEADZ(1) has the value 31 if BIT_SIZE(1) has the value 32.". 05-199r2: [327:15-16] (LGE), [327:29-30] (LGT), [328:10-11] (LLE), [328:24-25] (LLT) Replace the argument descriptions of LGE, LGT, LLE and LLT with: "STRING_A shall be of type default character or type ASCII character. STRING_B shall be of type character with the same kind type parameter as STRING_A." 05-268r3: [329:21+] After 13.7.68a LOG10(X), insert new subclause "13.7. LOG_GAMMA (X) Description. Log gamma function. Class. Elemental function. Argument. X shall be of type real. Its value shall not be a negative integer or zero. Result Characteristics. Same as X. Result Value. The result has a value equal to a processor-dependent approximation of the natural logarithm of the absolute value of the gamma function of X. Example. LOG_GAMMA(3.0) has the value 0.693 (approximately)." NOTES FROM THE EDITOR: (1) Description should probably be "Logarithm of the absolute value of the gamma function". (2) LOG_GAMMA should precede LOG10, at [329:14+]. 06-175r2: [329:23] 13.7.69 LOGICAL, Description paragraph, After "of logical" insert "or from bits to logical", [329:26] Arguments paragraph, L argument, After "of logical" insert "or bits", [329:30] Result Value paragraph, replace contents with "If L is of type logical, the result value is that of L. If L is of type bits and KIND(L) is greater than or equal to BITS_KIND(result), the result has the value whose internal representation is the same as the rightmost bits of L." NOTE TO THE EDITOR: SHOULD PROBABLY BE "physical representation", see TRANSFER. "J3 TECHNICAL NOTE This might not be a value. Seriously. We don't provide semantics for physical representations that don't represent a logical value. There are certainly systems that use the fastest test, which might be all-zero for a "FALSE" test and lowest-bit-set for a "TRUE" test... which is not going to give sensible results if you whack any old set of bits into the LOGICAL. Should we not say something about that here? At least with TRANSFER we give what the use can rely on, viz that converting LOGICAL to something else and back again gives you what you start with. Note that also with TRANSFER we carefully don't say that the result is a "value" of the result type, we only say what it's physical representation is. If L is of type bits and KIND(L) is less than BITS_KIND(result), the rightmost KIND(L) bits of the internal representation of the result value are the same as those of L, and the remaining bits of the result are zero." [329:31] Example paragraph, pluralise title, [330:1] Example paragraph, append new sentence "LOGICAL(BITS(.true.)) has the value true.". 06-175r2: [330:2-] Immediately before 13.7.70 MATMUL, insert new subclauses "13.7.69a MASKL (I, [,KIND]) <> Generate a left justified mask. <> Elemental function. <> I shall be of type integer. It shall be nonnegative and less than or equal to the kind type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. <> Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default bits type. <> The result value has its leftmost I bits set to 1 and the remaining bits set to 0. <> MASKL(12) has the value z'fff00000' if the default bits kind type parameter value is 32. 13.7.69b MASKR (I, [,KIND]) <> Generate a right justified mask. <> Elemental function. <> I shall be of type integer. It shall be nonnegative and less than or equal to the kind type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. <> Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default bits type. <> The result value has its rightmost I bits set to 1 and the remaining bits set to 0. <> MASKR(12) has the value z'00000fff' if the default bits kind type parameter value is 32.". 06-175r2: [331:6] 13.7.71 MAX, Arguments paragraph, After "integer, real," insert "bits,". [331:17+] Examples paragraph, append new sentence "MAX(b'10000',b'01111') has the value b'10000'.". 06-181r1: [331:27] 13.7.73 MAXLOC..., in the subclause title, After "KIND" insert ", BACK", twice. NOTE FROM THE EDITOR: Additional edit. 06-175r2: [331:32] 13.7.73 MAXLOC, Arguments paragraph, ARRAY argument, After "integer, real," insert "bits,". 06-181r1: [332:1+] 13.7.73, immediately before "Result Characteristics.", insert "BACK (optional) shall be scalar and of type logical.". NOTE FROM THE EDITOR: Additional. 06-181r1: [332:11-13] 13.7.73, Result Value paragraph, Case (i), Delete sentence "If more than one ... array element order." NOTE FROM THE EDITOR: Additional edit, factoring out the subscript values. 06-181r1: [332:19-21] 13.7.73, Result Value paragraph, Case (ii), Delete sentence "If more than one ... array element order." NOTE FROM THE EDITOR: Additional edit, factoring out the subscript values. 06-181r1: [332:28+] 13.7.73, Result Value paragraph, immediately after Case (iii), insert "If only one element has the maximum value, that element's subscripts are returned. Otherwise, if more than one element has the maximum value and BACK is absent or present with the value false, the element whose subscripts are returned is the first such element, taken in array element order. If BACK is present with the value true, the element whose subscripts are returned is the last such element, taken in array element order." NOTE FROM THE EDITOR: Make the simple case clear, and re-insert the factored-out subscript values, this time taking BACK into account. (RAH suggested putting this after the paragraph about CHARACTER; it's a close call, but I *think* it reads fractionally better before that paragraph.) 06-181r1: [332:33] 13.7.73, Examples paragraph, case (i), add to end of sentence "and the value of MAXLOC ([2,6,4,6],BACK=.TRUE.) is [4]". NOTE FROM THE EDITOR: Thanks to RAH for this example. 06-175r2: [333:2] 13.7.74 MAXVAL, Arguments paragraph, ARRAY argument, After "integer, real," insert "bits,". 06-175r2: [334:7+] Immediately before 13.7.76 MIN, insert new subclause "13.7.75a MERGE_BITS (I, J, MASK) <> Merge bits under mask. <> Elemental function. <> I shall be of type bits or integer. J shall have the same type and type parameters as I. J3 TECHNICAL NOTE If MERGE_BITS only handles "int,int" and "bits,bits" ... and not "int,bits" and "bits,int" ... why do IAND IOR IEOR have to handle the mixed-type cases? This is inconsistent. MASK shall be of type bits. KIND(MASK) shall be equal to BITS_KIND(I). <> Same as I. <> The result has the value of IOR(IAND(I,MASK), IAND(J,NOT(MASK))). <> MERGE_BITS(z'01234567',z'89abcdef',z'ffff0000') has the value z'0123cdef'.". 06-175r2: [334:11] 13.7.76 MIN, Arguments paragraph, After "integer, real," insert "bits,". [334:22+] Examples paragraph, append new sentence "MIN(b'10000',b'01111') has the value b'01111'.". 06-181r1: [334:32] 13.7.78 MINLOC..., in the subclause title, After "KIND" insert ", BACK", twice. NOTE FROM THE EDITOR: Additional edit. 06-175r2: [335:3] 13.7.78 MINLOC, Arguments paragraph, ARRAY argument, After "integer, real," insert "bits,". 06-181r1: [335:6+] 13.7.78, immediately before "Result Characteristics.", insert "BACK (optional) shall be scalar and of type logical.". NOTE FROM THE EDITOR: Additional edit. 06-181r1: [335:16-18] 13.7.78, Result Value paragraph, Case (i), Delete "If more than one ... array element order." NOTE FROM THE EDITOR: Additional edit, factoring out the subscript values. 06-181r1: [335:24-26] 13.7.78, Result Value paragraph, Case (ii), Delete "If more than one ... array element order." NOTE FROM THE EDITOR: Additional edit, factoring out the subscript values. 06-181r1: [335:33+] 13.7.78, Result Value paragraph, immediately after Case (iii), insert "If only one element has the minimum value, that elements subscripts are returned. Otherwise, if more than one element has the minimum value and BACK is absent or present with the value false, the element whose subscripts are returned is the first such element, taken in array element order. If BACK is present with the value true, the element whose subscripts are returned is the last such element, taken in array element order." NOTE FROM THE EDITOR: Make the simple case clear, and re-insert the factored-out subscript values, this time taking BACK into account. (Note positioning - same as in MAXLOC.) 06-181r1: [335:38] 13.7.78 MINLOC, Examples paragraph, case (i), add to end of sentence "and the value of MINLOC ((/ 4, 3, 6, 3 /), BACK = .TRUE.) is [4]". NOTE FROM THE EDITOR: Thanks to RAH for this example. 06-175r2: [336:9] 13.7.79 MINVAL, Arguments paragraph, ARRAY argument, After "integer, real," insert "bits,". 06-175r2: [338:26] 13.7.83 MVBITS, Arguments paragraph, FROM argument After "of type integer" insert "or bits", [339:1] TO argument, After "shall be a variable" Change "of type integer with the same" to "of the same type and". [339:4] Example paragraph, pluralise title and append new sentence "If TO has the initial value b'000000111111', the value of TO after the statement CALL MVBITS(b'000000000011', 0, 2, TO, 8) is b'001100111111'.". 06-175r2: [340:20] 13.7.87 NOT, Argument paragraph, After "of type integer" insert "or bits", [340:22,24] Result Value paragraph, Change "The result" to "If I is of type integer, the result" Append new sentence to the end of the paragraph "If I is of type bits, the result value is (.NOT. I)." [340:26] Example paragraph, pluralise title and append new sentence "NOT(z'ffff0000') has the value z'0000ffff'.". 05-264r3: [340:26+] After 13.7.87 NOT(I), insert new subclause "13.8.87a NORM2(X) Description. $L_2$ norm of an array. Class. Transformational function. Argument. X shall be of type real. It shall not be scalar. Result Characteristics. Scalar of the same type and kind type parameter value as X. Result value. The result has a value equal to a processor-dependent approximation to the $L_2$ norm of X if X is a rank-one array, the Frobenius norm of X if X is a rank-two array, and the generalized $L_2$ norm of X for higher-rank arrays. In all cases, this is the square root of the sum of the squares of all elements. Example. The value of NORM2( (/ 3.0, 4.0 /) ) is 5.0 (approximately). Note 13.16a It is recommended that the processor compute NORM2 in such a way that intermediate results do not overflow or underflow unless the final result would overflow or underflow, respectively.". NOTE FROM THE EDITOR: I HAVE DELETED THE DUPLICATE SPECIFICATION OF THE RESULT VALUE AS IT WAS NEEDLESSLY AND UNNECESSARILY REDUNDANT. NOTE TO THE EDITOR: SIMPLIFY THE RESULT VALUE FURTHER? 06-174r3: [341:30+] Immediately before 13.7.89 PACK, insert new subclause "13.7.88a NUM_IMAGES() <> Returns the number of images. <> Inquiry function. <> None. <> Default integer scalar. <> The number of images. <> To use image 1 to read data and broadcast it to other images: REAL :: P[*] ... IF (THIS_IMAGE()==1) THEN READ(6,*)P DO I = 2, NUM_IMAGES() P[I] = P END DO END IF SYNC_ALL NOTE 13.16b The following two functions are useful in connection with NUM_IMAGES. INTEGER FUNCTION LOG2_IMAGES() ! Returns the base-2 logarithm of the number of images, ! truncated to an integer. LOG2_IMAGES = LOG(NUM_IMAGES()+0.5)/LOG(2.0) END FUNCTION LOG2_IMAGES INTEGER FUNCTION REM_IMAGES() ! Returns MOD(NUM_IMAGES(),2**LOG2_IMAGES()). REM_IMAGES = MOD(NUM_IMAGES(),2**LOG2_IMAGES()) END FUNCTION REM_IMAGES [end NOTE]". 06-175r2: [342:17-] Immediately before 13.7.90 PRECISION, insert new subclauses "13.7.89a PARITY (MASK [,DIM]) <> Determine whether an odd number of values are true in MASK along dimension DIM. <> Transformational function. <> MASK shall be of type logical. It shall not be scalar. DIM (optional) shall be a scalar and of type integer with a value in the range 1 <= DIM <= where is the rank of MASK. The corresponding actual argument shall not be an optional dummy argument. <> The result is of type logical with the same kind type parameter as MASK. It is scalar if DIM is absent or if MASK has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of MASK. <> : The result of PARITY(MASK) has the value true if an odd number of the elements of MASK are true, and false otherwise. : If MASK has rank one, PARITY(MASK,DIM) has a value equal to that of PARITY(MASK). Otherwise, the value of element () of PARITY(MASK,DIM) is equal to PARITY(MASK()) <> : The value of PARITY([T,T,T,F]) is true if T has the value true and F has the value false. | T T F | : If B is the array | T T T |, where T has the value true and F has the value false, then PARITY(B,DIM=1) is [F, F, T] and PARITY(B, DIM=2) is [F, T]. 13.7.89b POPCNT (I [,KIND]) <> Return the number of one bits. <> Elemental function. <> I shall be of type integer or bits. KIND (optional) shall be a scalar integer initialization expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of the default integer type. <> If I is of type integer, the result value is the number of one bits in the sequence of bits of I. The model for the interpretation of an integer value as a sequence of bits is in 13.3. If I is of type bits, the result value is the number of one bits in I. <> POPCNT([1,2,3,4,5,6]) has the value [1,1,2,1,2,2]. POPCNT(z'ffff0000') has the value 16. If B is of type bits, POPCNT(HUGE(B)) has the same value as KIND(B). 13.7.89c POPPAR (I [,KIND]) <> Return the bitwise parity. <> Elemental function. <> I shall be of type integer or bits. KIND (optional) shall be a scalar integer initialization expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of the default integer type. <> POPPAR(I) has the value 1 if POPCNT(I) is odd, and 0 if POPCNT(I) is even. <> POPPAR([1,2,3,4,5,6]) has the value [1,1,0,1,0,0]. POPPAR(z'ffff0000') has the value 0.". 06-175r2: [344:8-9] REJECTED: 13.7.94 RANDOM_NUMBER, Description paragraph, Change "number" to "value" and "numbers" to "values". NOTE FROM THE EDITOR: Since we have established that bits are numbers (individual bits are 0 and 1, these are usually recognised as numbers) this seems to be pointless fiddling. NOTE TO THE EDITOR: Fix the rest of this sentence too, or put in a J3 NOTE, because it does not make sense for bits (they do not satisfy 0<=x<1). [344:11-13] Argument paragraph, replace with "HARVEST shall be of type real or bits. It is an INTENT(OUT) argument. It may be a scalar or an array variable. If it is of type real, it is assigned pseudorandom numbers from a uniform distribution in the interval 0 <= < 1. If it is of type bits, it is assigned pseudorandom values with each of the KIND(HARVEST) bits of each value having a probability of approximately 0.5 of being 1.", [344:15+] Example paragraph, After the line "REAL X, ..." insert the line "BITS B". [344:19+] Append two lines to the example "CALL RANDOM_NUMBER(B) ! B contains a uniformly random collection of 0 and 1 bits.". 06-175r2: [346:1] 13.7.97 REAL, Arguments paragraph, A argument, Change "or complex, or a " to "complex, or bits", [346:5-6] Result Characteristics paragraph, Case (i), Change "integer or real" to "integer, real, or bits" twice. [346:11-13] Case (iii), Delete, [346:16] Result Value paragraph, Case (i), append new sentences "If A is of type bits and KIND(A) is greater than or equal to BITS_KIND(result), the result has the value whose physical representation is the same as the rightmost bits of A. If A is of type bits and KIND(A) is less than BITS_KIND(result), the rightmost KIND(A) bits of the physical representation of the result value are the same as those of A, and the remaining bits of the result are zero.", [346:19-22] Result Value, Case (iii), Delete, [346:24] Examples paragraph, append new sentence "REAL(z'7f800000') has the value positive infinity if the default real kind is IEEE single precision.". 06-175r2: [349:6+] Immediately before 13.7.104 SELECTED_CHAR_KIND, insert new subclause "13.7.103a SELECTED_BITS_KIND (N) <> Returns a value of the kind type parameter of a bits type with N bits. <> Transformational function. <> N shall be scalar and of type integer. <> Default integer scalar. <> The result value is N if the processor supports a bits type with a kind type parameter equal to N; otherwise the result value is -1. <> If the NUMERIC_STORAGE_SIZE value for the processor is 32, SELECT_BITS_KIND(43) has the value 43.". 05-232r1: [350:12] 13.7.106 "SELECTED_REAL_KIND...", title, after "P, R" insert ", RADIX". 05-232r1: [350:13] 13.7.106, first paragraph "Description", - change "P digits and" to "P digits," - after "at least R" insert ", and a radix of RADIX". Making the whole description read "Returns a value of the kind type parameter of a real type with decimal precision of a least P digits, a decimal range of at least R, and a radix of RADIX." 05-232r1: [350:18+] 13.7.106, at the end of the "Arguments." paragraph, insert "RADIX (optional) shall be scalar and of type integer." 05-232r1: [350:21] 13.7.106, "Result Value" paragraph, after the first sentence "If ... value zero.", insert "If RADIX is absent, there is no requirement on the radix of the selected kind." 05-232r1: [350:21-29] 13.7.106, "Result Value" paragraph, replace the second sentence "The result has ... but not together." with the following two paragraphs, and make the remaining sentence ("If more ...") into a separate paragraph as well. "The result has a value equal to a value of the kind type parameter of a real type with decimal precision, as returned by the function PRECISION, of at least P digits, a decimal exponent range, as returned by the function RANGE, of at least R, and a radix, as returned by the function RADIX, of RADIX, if such a kind type parameter is available on the processor. Otherwise, the result is -1 if the processor supports a real type with radix RADIX and exponent range of at least R but not with precision of at least P, -2 if the processor supports a real type with radix RADIX and precision of at least P but not with exponent range of at least R, -3 if the processor supports a real type with radix RADIX but with neither precision of at least P nor exponent range of at least R, -4 if the processor supports a real type with radix RADIX and either precision of at least P or exponent range of at least R but not both together, and -5 if the processor supports no real type with radix RADIX." 06-175r2: [351:19+] Immediately before 13.7.109 SIGN, insert new subclauses "13.7.108a SHIFTA (I, SHIFT) <> Performs an arithmetic right shift. <> Elemental function. <> I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The result has the value obtained by shifting the bits of I to the right SHIFT bits and replicating the leftmost bit of I in the left SHIFT bits. J3 TECHNICAL NOTE This does not just assume integers are binary, but that they are twos complement binary. Other machines have existed and I believe even still exist. If this is meant to be an *arithmetic* shift surely it should give the right answer on all machines? After all, if we are only going to support binary twos complement, we can define negative integer bit patterns (and we have not done that, nor should we). NOTE: I am complaining about the <>, not about the functionality. Or maybe I'm complaining that the functionality doesn't match my signed-magnitude machines version. Who knows. If SHIFT is zero the result is I. Bits shifted out from the right are lost. The model for the interpretation of an integer value as a sequence of bits is in 13.3. J3 TECHNICAL NOTE Which does not interpret values with the top bit set, i.e. is completely irrelevant to this function. 13.3 says that if it has the top bit set, the interpretation is "processor dependent"; this is not useful for this function. Maybe there is no fix here... <> SHIFTA(b'10000',2) has the value b'11100'. 13.7.108b SHIFTL (I, SHIFT) <> Performs a left shift. <> Elemental function. <> I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The value of the result is ISHFT(I,SHIFT). <> SHIFTL(3,1) has the value 6. SHIFTL(b'00001',2) has the value b'00100'. 13.7.108c SHIFTR (I, SHIFT) <> Performs a right shift. <> Elemental function. <> I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The value of the result is ISHFT(I,-SHIFT). <> SHIFTR(3,1) has the value 1. SHIFTR(b'10000',2) has the value b'00100'.". 05-204r2: [352:15] 13.7.111 SINH(X), Argument paragraph, After "real" insert "or complex". 05-204r2: [352:17] 13.7.111 SINH(X), Result Value paragraph, append: "If X is of type complex its imaginary part is regarded as a value in radians." 05-234r2: [353:19] 13.7.144 SPREAD, "Arguments" paragraph, SOURCE argument, last sentence, change "less than 7" to "less than 15". 05-204r2: [355:16] 13.7.118 TAN(X), Argument paragraph, After "real" insert "or complex". 05-204r2: [355:18-19] 13.7.118 TAN(X), Result Value paragraph - delete ", with X regarded as a value in radians" - append to paragraph "If X is of type real, it is regarded as a value in radians. If X is of type complex, its real part is regarded as a value in radians." 05-204r2: [355:24] 13.7.119 TANH(X), Argument paragraph, After "real" insert "or complex". 05-204r2: [355:26] 13.7.119 TANH(X), Result Value paragraph, append: "If X is of type complex its imaginary part is regarded as a value in radians." 06-174r3: [356:1+] Immediately before 13.7.120 TINY(X), insert new subclause "13.7.119a THIS_IMAGE() or THIS_IMAGE(CO_ARRAY [,DIM]) <> Returns the index of the invoking image, a single co-subscript, or a list of co-subscripts. <> Inquiry function. <> CO_ARRAY (optional) shall be a co-array of any type. DIM (optional) shall be scalar and of type default integer. Its value shall be in the range 1<=DIM<=n where n is the co-rank of CO_ARRAY. It shall not be an absent optional dummy argument. <> Type default integer. It is scalar if CO_ARRAY is absent or DIM is present; otherwise, the result has rank one and its size is equal to the co-rank of CO_ARRAY. <> <> The result of THIS_IMAGE() is a scalar with a value equal to the index of the invoking image, and lies in the range 1, ..., NUM_IMAGES(). <> The result of THIS_IMAGE(CO_ARRAY) is the sequence of co-subscript values for CO_ARRAY that would specify the invoking image. J3 TECHNICAL NOTE This does not appear to be adequately specified. The mapping between co-subscripts (or rather, co-subscript lists) and image indexes is done by handwaving analogy. It is probably not necessary to repeat the formulae, but we need to say that we use those formulae in a more rigorous way. <> The result of THIS_IMAGE(CO_ARRAY,DIM) is the value of co-subscript DIM in the sequence of co-subscript values for CO_ARRAY that would specify the invoking image. <> The following employs the first image to read data. The other images then copy the data. IF (THIS_IMAGE()==1) READ(*,*)P SYNC_ALL P = P[1] NOTE 13.17a For an example of a module implementing a function similar to the intrinsic IMAGE_INDEX, see subclause \ref{DC:Module for THIS_IMAGE and IMAGE_INDEX}. [end NOTE]". 06-175r2: [356:10+] Immediately before 13.7.121 TRANSFER, insert new subclause "13.7.120a TRAILZ (I [,KIND]) <> Count the number of trailing zero bits. <> Elemental function. <> I shall be of type integer or bits. KIND (optional) shall be a scalar integer initialization expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. <> If all of the bits of I are zero, the result value is BIT_SIZE(I). Otherwise, the result value is the position of the rightmost 1 bit in I, where the rightmost bit position is 0. The model for the interpretation of an integer value as a sequence of bits is in 13.3. <> TRAILZ(8) has the value 3. TRAILZ(b'101101000') has the value 3.". 06-167r1: (combined with 06-174r3:) [360:3] 13.8.2 The ISO_FORTRAN_ENV intrinsic module, Insert ", derived type, and intrinsic procedures" after "named constants". 06-167r1: [360:6+] 13.8.2, insert new subclauses after the end of subclause 13.8.2.1 CHARACTER_STORAGE_SIZE, "13.8.2.1A COMPILER_OPTIONS() Description. Returns a processor dependent string describing the options that controlled the program translation phase. Class. Inquiry function. Argument. None Result Characteristics. Default character scalar with processor-dependent length. Result Value. A processor-dependent value which describes the options that controlled the translation phase of program execution. Example: COMPILER_OPTIONS() might have the value "/OPTIMIZE /FLOAT=IEEE /CHECK:SUBSCRIPTS". 13.8.2.1B COMPILER_VERSION() Description. Returns a processor-dependent string identifying the program translation phase. Class. Inquiry function. Argument. None Result Characteristics. Default character scalar with processor-dependent length. Result Value. A processor-dependent value that identifies the name and version of the program translation phase of the processor. Example: COMPILER_VERSION() might have the value "Super-fast KL-10 Compiler Version 0.1". NOTE: For both COMPILER_OPTIONS and COMPILER_VERSIONS the processor should include relevant information that could be useful in solving problems found long after the translation phase. For example, compiler release and patch level, default compiler arguments, environment variable values, and run time library requirements might be included. A processor might include this information in an object file automatically, without the user needing to save the result of this function in a variable." 06-174r3: [360:14-] Immediately before 13.8.2.4 INPUT_UNIT, insert new subclause "13.8.2.3a IMAGE_TEAM The derived type IMAGE_TEAM shall have only private components. Scalar objects of this type identify teams of images." NOTE FROM THE EDITOR: Substantially rewrote this to delete the junk. COMMENT: (1) Note 13.19 claims that co-arrays are not permitted to be of type IMAGE_TEAM, but I found no normative text which supported that. Anyway, it would be useful to be able to access an IMAGE_TEAM directly without having to build one locally from an image list. (2) I deleted "collaborate in computations" because (a) it is unnecessary waffle, and (b) all images collaborate in the computation anyway. NOTE TO THE EDITOR: [397:2] in 04-007 should say "only private" too. NOTE TO THE EDITOR: Subgroup say: > *** Teams are always built locally from an image list using the > FORM_TEAM intrinsic. You would not want to use in this image a team > variable value from a different image. The values may differ among the > images of a team. These variables might contain detailed information > on such things as which images are its neighbors in the hardware, or > the location of the image in a reduction tree. > > As you noted, the normative text supporting Note 13.19 is missing. This > was removed recently, but we feel it should be put back. The "special" > derived types IMAGE_TEAM, C_PTR, and C_FUNPTR are very likely to contain > information that is specific to the image where it was defined. Use of > these data on a different image could lead to various errors. The > changes required are: > > 1) Restore Note 13.19. > > 2) Modify the edit for [50:25+] to add another constraint: > > "C440d (R440) A component of derived type image_team (13.8.2.x), c_ptr, > or c_funptr (15.2.2) shall not be a co-array." > > 3) In the edit at [73:1+] replace the text for C517b with: > > "C517b (R501) A co-array shall not be of derived type image_team > (13.8.2.x) or c_ptr (15.2.2) and shall not have the POINTER attribute." > > 4) In the edit at [105:9+] replace the text for C613b with: > > "C613b (R613) A that is a co-indexed object shall not be of a > type that has a pointer ultimate component or has a subcomponent of > derived type image_team (13.8.2.x), c_ptr, or c_funptr (15.2.2)." NOTE CONTINUED: Consider acting on this if time permits. 06-141: [360:17+] Insert new subclause "13.8.2.4a INT8, INT16, INT32, and INT64 The values of these default integer scalar named constants shall be those of the kind type parameters that specify an INTEGER type whose storage size expressed in bits is 8, 16, 32, and 64 respectively. If, for any of these constants, the processor supports more than one kind of that size, it is processor-dependent which kind value is provided. If the processor supports no kind of a particular size, that constant shall be -2 if the processor supports kinds of a larger size and -1 otherwise." 06-138r2: [360:26+] Immediately after the end of subclause 13.8.2.6 IOSTAT_EOR, Insert new subclause "<<13.8.2.7 IOSTAT_INQUIRE_INTERNAL_UNIT>> The value of the default integer scalar constant IOSTAT_INQUIRE_INTERNAL_UNIT is assigned to the variable specified in an IOSTAT= specifier in an INQUIRE statement (9.9.1) if a identifies an internal unit in that statement. <> This can only occur when a user defined derived type input/output procedure is called by the processor as the result of executing a parent data transfer statement for an internal unit. (end note)" 06-141: [360:33+] Insert new subclause "13.8.2.8a REAL32, REAL64, and REAL128 The values of these default integer scalar named constants shall be those of the kind type parameters that specify a REAL type whose storage size expressed in bits is 32, 64, and 128 respectively. If, for any of these constants, the processor supports more than one kind of that size, it is processor-dependent which kind value is provided. If the processor supports no kind of a particular size, that constant shall be -2 if the processor supports kinds of a larger size and -1 otherwise." Missing edit from 05-232r1: [370:32] 14.9.3 Kind function, argument list, insert ",RADIX" after"[P,R". [370:33] Change "and range" to ", range, and radix". 05-232r1: [378:4] 14.10.17 "IEEE_SELECTED_REAL_KIND...", title, after "P, R" insert ", RADIX". 05-232r1: [378:5-6] 14.10.17, "Description" paragraph, - change "P digits and" to "P digits," - after "at least R" insert ", and a radix of RADIX". Making the whole description read "Returns a value of the kind type parameter of an IEEE real type with decimal precision of a least P digits, a decimal range of at least R, and a radix of RADIX." 05-232r1: [378:11+] 14.10.17, at the end of the "Arguments." paragraph, insert "RADIX (optional) shall be scalar and of type integer." 05-232r1: [378:13] 14.10.17, "Result Value" paragraph, insert new first sentences "If P or R is absent, the result value is the same as if it were present with the value zero. If RADIX is absent, there is no requirement on the radix of the selected kind." 05-232r1: [378:13-17] 14.10.17, "Result Value" paragraph, replace the first sentence "The result ... neither is available." with "The result has a value equal to a value of the kind type parameter of an IEEE real type with decimal precision, as returned by the function PRECISION, of at least P digits, a decimal exponent range, as returned by the function RANGE, of at least R, and a radix, as returned by the function RADIX, of RADIX, if such a kind type parameter is available on the processor. Otherwise, the result is -1 if the processor supports an IEEE real type with radix RADIX and exponent range of at least R but not with precision of at least P, -2 if the processor supports an IEEE real type with radix RADIX and precision of at least P but not with exponent range of at least R, -3 if the processor supports an IEEE real type with radix RADIX but with neither precision of at least P nor exponent range of at least R, -4 if the processor supports an IEEE real type with radix RADIX and either precision of at least P or exponent range of at least R but not both together, and -5 if the processor supports no IEEE real type with radix RADIX." 06-175r2: [391:25+] 15.1.1 Named constants and derived types in the module, after the second paragraph, insert new paragraph "The value of C_UINT shall be a valid value for a bits kind type parameter of the processor. The values of C_USHORT, C_ULONG, C_ULONG_LONG, C_UNSIGNED_CHAR, C_UINT8_T, C_UINT16_T, C_UINT32_T, C_UINT64_T, C_UINT_LEAST8_T, C_UINT_LEAST16_T, C_UINT_LEAST32_T, C_UINT_LEAST64_T, C_UINT_FAST8_T, C_UINT_FAST16_T, C_UINT_FAST32_T, C_UINT_FAST64_T, C_UINTMAX_T, C_UINTPTR_T, C_FLOAT_BITS, C_DOUBLE_BITS, C_LONG_DOUBLE_BITS, C_FLOAT_COMPLEX_BITS, C_DOUBLE_COMPLEX_BITS, C_LONG_DOUBLE_COMPLEX_BITS, and C_BOOL_BITS shall each be a valid value for a bits kind type parameter on the processor, -1 if the companion C processor defines the corresponding C type and there is no interoperating Fortran processor kind, or -2 if the C processor does not define the corresponding C type.". NOTE FROM THE EDITOR: I do not see the justification for C_FLOAT_BITS et al. 06-140r1: [395:32-] Immediately before 15.2 Interoperability between Fortran and C entities, insert new subclause "15.1.2.6 C_SIZEOF (X) Description. Returns the size of X in bytes. Class. Inquiry function. Argument. X shall be an interoperable data entity that is not an assumed-size array. Result Characteristics. Scalar integer of kind C_SIZE_T (15.2.1). Result Value. If X is scalar, the result value is the value that the C processor returns as the result of applying the sizeof operator (C International Standard, subclause 6.5.3.4) to an object of a type that interoperates with the type and type parameters of X. If X is an array, the result value is the value that the C processor returns as the result of applying the sizeof operator to an object of a type that interoperates with the type and type parameters of X, multiplied by the number of elements in X." 06-175r2: [396:14+] 15.2.1 Interoperability of intrinsic types, Table 15.2, add new table section after the row containing "C_INTPTR_T", "----------------------------------------------------------------- | C_UINT | unsigned int or int | C_USHORT | unsigned short or short | C_ULONG | unsigned long or long | C_ULONG_LONG | unsigned long long or | | long long | C_UNSIGNED_CHAR | unsigned char or | | signed char | C_UINT8_T | uint8_t or int8_t | C_UINT16_T | uint16_t or int16_t | C_UINT32_T | uint32_t or int32_t BITS | C_UINT64_T | uint64_t or int64_t | C_UINT_LEAST8_T | uint_least8_t or | | int_least8_t | C_UINT_LEAST16_T | uint_least16_t or | | int_least16_t | C_UINT_LEAST32_T | uint_least32_t or | | int_least32_t | C_UINT_LEAST64_T | uint_least64_t or | | int_least64_t | C_UINT_FAST8_T | uint_fast8_t or | | int_fast8_t | C_UINT_FAST16_T | uint_fast16_t or | | int_fast16_t | C_UINT_FAST32_T | uint_fast32_t or | | int_fast32_t | C_UINT_FAST64_T | uint_fast64_t or | | int_fast64_t | C_UINTMAX_T | uintmax_t or intmax_t | C_UINTPTR_T | uintptr_t or intptr_t | C_FLOAT_BITS | float | C_DOUBLE_BITS | double | C_LONG_DOUBLE_BITS | long double | C_FLOAT_COMPLEX_BITS | float _Complex | C_DOUBLE_COMPLEX_BITS | double _Complex | C_LONG_DOUBLE_COMPLEX_BITS | long double _Complex | C_BOOL_BITS | _Bool". NOTE FROM THE EDITOR: Changed C_USIGNED_CHAR to C_UNSIGNED_CHAR. 06-175r2: [397:1-] 15.2.1, at the very end after note 15.9, insert note "Note 15.9a If a variable of type bits is the actual argument corresponding to an unsigned integer parameter of a C function and is interoperable with that parameter, or the unsigned integer result of a C function is assigned to a variable of type bits that is interoperable with the function result, the I format can be used to output the correct form of the unsigned integer value. [end Note]". TR 19767: [403:38+] 15.4.1 Binding labels for procedures, after second paragraph, insert "C1506 A procedure defined in a submodule shall not have a binding label unless its interface is declared in the ancestor module. TR 19767: [405:12+] 16 "Scope, association, and definition", first numbered list, insert new item "(4a) A submodule idenfitifer({ref new 11.2.2}), TR 19767: [405:19] 16.1 Scope of global identifiers, first paragraph, second sentence, before the first "program unit" insert "non-submodule". TR 19767: [405:22] 16.1, first paragraph, after second sentence (ends "same program."), insert new sentence "The submodule identifier of a submodule is a global identifier and shall not be the same as the submodule identifier of any other submodule." TR 19767: [406:1-] 16.1, between Note 6.2 and the last paragraph insert "Note 16.2a Submodule identifiers are global identifiers, but since they consist of a module name and a descendant submodule name, the name of a submodule can be the same as the name of another submodule so long as they do not have the same ancestor module." TR 19767: [406:6] 16.2 Scope of local identifiers, first numbered list, item (1), after "abstract interfaces" insert ", module procedure interfaces". 06-168r2: [406:7] 16.2 Scope of local identifiers, first numbered list, item (1), Before "and statement labels", insert "macros,". TR 19767: [406:20] 16.2, paragraph before Note 16.3, after "(4.5.9)", insert ", and a separate module procedure shall have the same name as its corresponding module procedure interface body". 05-237r4: [409:15-410:4] 16.3 Statement and construct entities, replace "FORALL construct" with "FORALL or DO CONCURRENT construct" in the following eight locations: 409:15 409:24 409:28 409:42 409:43 410:1 410:2 410:4 06-168r2: [409:16] 16.3 Statement and construct entities, first paragraph, Append new sentence "A macro local variable is a construct entity". 06-142: [409:16+] 16.3, first paragraph, append new sentence: "An entity that is declared in a BLOCK construct and is not accessed by use association is a construct entity." 05-237r4: [409:26] 16.3, 3rd paragraph, 2nd sentence, replace "includes the FORALL" with "includes the FORALL statement or FORALL or DO CONCURRENT construct". {NOTE FROM THE EDITOR: Ugh. No J3 action required.} 06-142: [410:14+] 16.3, append paragraph to subclause "If a global or local identifier accessible in the scoping unit of a BLOCK construct is the same as a construct entity of that BLOCK construct, the name is interpreted within the BLOCK construct as that of the construct entity." 06-168r2: [410:14+] 16.3, after the last paragraph, immediately before 16.4 Association, Append new paragraph "The macro local variables of a macro definition have the scope of the macro definition. If a global or local identifier accessible in the scoping unit of a macro definition is the same as a macro local variable, the name is interpreted within the macro definition as that of the macro local variable. Elsewhere in the scoping unit, the name is interpreted as the global or local identifier." NOTE TO THE EDITOR: Factor out this boilerplate everywhere it occurs, replacing it with a single paragraph stating "If a global or local identifier is the same as a construct entity, the name is interpreted within the construct as that of the construct entity. Elsewhere in the scoping unit, the name is interpreted as the global or local identifier." {This is at [406:2-5] and [406:11-14]. Note that the FORALL statement part of [406:2-5] was already redundant with [405:37-40].} TR 19767: [411:2] 16.4.1.3 Host association, first paragraph, first sentence, after "module subprogram" insert ", a module procedure interface body". TR 19767: [411:3] 16.4.1.3, first paragraph, second sentence, after "interface body", insert "that is not a module procedure interface body". TR 19767: [411:4] 16.4.1.3, first paragraph, after the second sentence, insert new sentence "A submodule has access to the named entities of its parent by host association." TR 19767: [411:7] 16.4.1.3, first paragraph, last sentence, after "abstract interfaces", insert ", module procedure interfaces". 06-168r2: [411:8] 16.4.1.3 Host association, first paragraph, last sentence, before "and namelist groups" insert "macros,". NOTE TO THE EDITOR: immediately before this, delete the pointless cross-ref for "generic identifiers". We don't have cross-refs for anything else in the list, and "generic identifiers" appears in the index already. NOTE TO THE EDITOR: The first two sentences of this paragraph are wrong. Host association applies to identifiers, not just names (both these sentences say "named entities"). Fix, perhaps by incorporating the last sentence into the first and then we can just say "accessed entities" throughout the rest. This is basically how we do it for use assoc... 06-168r2: [411:29+] 16.4.1.3, numbered list, insert new item near the end "(14a) The name of a macro". TR 19767: [411:34] 16.4.1.3, paragraph after the numbered list, second sentence, change "or a subprogram," to "or a subprogram that does not define a separate module procedure,". TR 19767: [412:1+2] 16.4.1.3, Note 16.9, after "An interface body" insert "that is not a module procedure interface body" (before "accesses by host association..."). 06-108r1: [414:18+] 16.4.2.1.1 Events that cause pointers to become associated, end of the list, add a new item "(3) The pointer is a dummy argument and the actual argument is not a pointer." NOTE TO EDITOR: This item should probably precede the one from 05-279. 05-279: [414:18+] 16.4.2.1.1 Events that cause pointers to become associated, end of the list, add a new item "(3) The pointer is an ultimate component of an object of a type for which default initialization is specified for the component, and the corresponding initializer is an initialization target, and" And copy the three subsidiary items of item (4) in 16.4.2.1.2 "Events that cause pointers to become disassociated" at [414:26-30] --- the first of which begins "a procedure is invoked ..." to here. 05-279: [414:25] 16.4.2.1.2 Events that cause pointers to become disassociated, within the fourth item (which begins "The pointer is an ultimate component ..."), Before "is specified" insert ", and the corresponding initializer is a reference to the intrinsic function NULL,". 05-202r1: [415:7+] 16.4.2.1.3 "Events that cause the pointer association status of pointers to become undefined", numbered list, after item (4) insert a new (top level) item "(4a) Execution of the host instance of a procedure pointer is completed by execution of a RETURN or END statement." TR 19767: [415:15+] 16.4.2.1.3, after numbered list item (5)(d), insert new level 2 item "(d+) Is in the scoping unit of a submodule if any scoping unit in that submodule or any of its descendant submodules is in execution,". 06-175r2: [416:8] 16.4.3.1 Storage sequence, numbered list, item (1), Change "or default logical" to "default logical, or default bits". 06-175r2: [416:11+] 16.4.3.1, after item (2), add new list item "(2a) A nonpointer scalar object of type bits with a kind type parameter that is an integer multiple, N, of the size of a numeric storage unit occupies N contiguous numeric storage units. The ordering of these consecutive numeric storage units is processor dependent. A nonpointer scalar object of type bits with a kind type parameter that is not an integer multiple of the size of a numeric storage unit occupies an unspecified storage unit that is different for each such kind value.". NOTE FROM THE EDITOR: I DON'T SEE WHAT "THE ORDERING ..." SENTENCE GIVES YOU. YOU PROBABLY MEAN TO SAY SOMETHING MEANINGFUL HERE, BUT YOU HAVE NOT SUCCEEDED. NOTE TO THE EDITOR: This is something subtle about endianness. x(1)//x(2) gives the same result on all machines, but whether when that is stored x(1) or x(2) occurs first is processor (endian) dependent. Append "J3 TECHNICAL NOTE Does defining a (numeric) storage unit with a bits value define it for other types? Presumably not. What about the other way round? How does this interact with argument association - since the types are different, defining the dummy isn't going to define the actual!" 06-175r2: [416:18,20] 16.4.3.1, item (6), change hardcoded item numbers "(1)-(5)" to "(1)-(6)" and "(4)" to "(5)". 05-273r3: [416:24] 16.4.3.1 Storage sequence, numbered list, item (8), append sentence: "A pointer that has the CONTIGUOUS attribute occupies a storage unit that is different from that of a pointer that does not have the CONTIGUOUS attribute." 06-175r2: [416:28+] 16.4.3.1, at the end, append new paragraph and note "Two objects for which the intrinsic function BITS_KIND returns the same value occupy the same amount of storage. Note 16.13a A nonpointer nonallocatable scalar BITS object with a KIND value that is not an integer multiple of the size of a numeric storage unit in bits might be stored in a memory region larger than the minimum required to represent the value. For example, if BITS_KIND(x) has the value 13, the storage size for x might be 16 bits. Each element of a BITS array occupies the same size memory region as a scalar BITS object of the same kind.". 05-210r2: [418:16-17] Replace the first sentence of the second paragraph of 16.4.5 Establishing associations -- the one that begins "For argument association..." -- by "For argument association, if the dummy argument is not a pointer and the corresponding actual argument is a pointer, the pre-existing entity is the target of that pointer. Otherwise the pre-existing entity is the corresponding actual argument. In either case, the associating entity is the dummy argument." 05-202r1: [418:18] Within the second paragraph of 16.4.5 Establishing associations, before the third sentence -- the one that begins "If the host scoping unit...: -- insert a new sentence: "If an internal procedure is invoked via a dummy procedure or procedure pointer, the pre-existing entity that participates in the association is the one from the host instance." Then replace "If" by "Otherwise if". 06-142: [420:2] 16.5.3 Variables that are initially defined, item (3), Change "either saved or are declared in a main program, MODULE," To "saved, local variables of a main program, or declared in a MODULE". 05-278r2: (modified by 06-154r4:) [420:11-13] 16.5.5 Events that cause variables to become defined, numbered list, first item, Replace both occurrences of "variable that precedes the equals" by "variable". 06-174r3: [421:22,24] 16.5.5 Events that cause variables to become defined, items (17) and (18) (about STAT= and ERRMSG= respectively), change "or DEALLOCATE" to ", DEALLOCATE, NOTIFY, QUERY, SYNC_ALL, SYNC_IMAGES, SYNC_MEMORY, or SYNC_TEAM" in both items. NOTE TO THE EDITOR: EDITORIAL FIX [421:25] "the becomes defined" -> "the variable specified by the ERRMSG= specifier becomes defined". 06-142: [421:43+] 16.5.5, Append new item "(27) Execution of the BLOCK statement of a BLOCK construct that has an unsaved nonpointer nonallocatable local variable causes all nonpointer default-initialized subcomponents of the variable to become defined." 06-138r2: [421:43+] 16.5.5, Append new item "(28) Execution of an OPEN statement containing a NEWUNIT= specifier causes the specified integer variable to become defined." TR 19767: [422:14-15] 16.5.6 Events that cause variables to become undefined, numbered list item (3)(c), - after "nonfinalizable local variables of a module" insert "or submodule"; - after "referencing the module" insert "or accessing the submodule". TR 19767: [422:16-17] 16.5.6, numbered list item (3)(d), - after "finalizable local variables of a module" insert "or submodule"; - after "referencing the module" insert "or accessing the submodule". 05-237r4: [423:18] 16.5.6 Events that cause variables to become undefined, item (15), replace "FORALL construct" with "FORALL or DO CONCURRENT construct". 05-237r4: [423:18+] 16.5.6, after item (15), add a new item "(15a) When a DO CONCURRENT construct terminates, a variable that is defined or becomes undefined during more than one iteration of the construct becomes undefined." 06-142: [423:28+] 16.5.6, numbered list, append new item "(19) When a BLOCK construct terminates, its unsaved local variables become undefined." 05-278r2: [423:28+2-3] 16.5.6 Events that cause variables to become undefined, near the end, in Note 16.19, Replace "variable that precedes the equals" by "variable". (06-155): [423:33] 16.5.7 Variable definition context, numbered list, item 1, "" -> "". 06-138r2: [423:42+] 16.5.7 Variable definition context, numbered list, after item 9, After "A definable variable in an INQUIRE statement," Add new item "(9a) A NEWUNIT= specifier in an OPEN statement,". NOTE TO THE EDITOR: Item (9) is broken - it needs to exclude UNIT= and FILE=. 06-174r3: [423:43] 16.5.7, numbered list item (10) beginning "A ...", change "or a " to ", , , , , , , or ". NOTE TO THE EDITOR: We probably don't need the list of statements here... 06-174r3: [423:43+] 16.5.7, after item (10), insert new item "(10a) A READY= specifier in a QUERY statement". 06-154r4: [424:4+] 16.5.7 Variable definition context, append new paragraph "If a reference to a function appears in a variable-definition context the result of the function reference shall be a pointer that is associated with a definable target. That target is the variable that becomes defined or undefined.". 05-278r2: (deleted by 06-154r4:) [425:26+] Annex A, No not add a glossary item. 05-278r2: [425:27] Annex A, Replace the glossary item for <>: "<> (\ref{D7:General form}): A statement that evaluates an expression and assigns its value to a variable." 05-205r2: [426:8] Annex A, definition of <>, delete the first "DO". 06-174r3: [427:1-] Annex A, alphabetically insert new items "<> (2.4.5a) : A data entity that has nonzero co-rank. It has the same shape on every image and its values may be referenced or defined by any image. <> (2.4.5a) : For a co-array, the limits within which the values of its co-subscripts of its co-indexed objects shall lie. <> (2.4.5a) : An object whose designator includes an . <> (2.4.5a) : The number of co-dimensions of a co-array. <> (2.4.5a) : One of the list of scalar integer expressions in an .". [427:2+] "<> (13.1) : An intrinsic subroutine that has an argument of type IMAGE_TEAM." [427:18+] "<> (9.4.5) : The set of images that are permitted to reference a particular external input-output unit.". 06-142: [427:24] Annex A, "construct" definition, before "DO" insert "BLOCK". 05-200r1: [428:32-33] Annex A, definition of <>, change "component ... substring selectors" to "subobject selectors". 06-168r2: [429:11] Annex A, entry for "entity", add macros to the list. 06-174r3: [430:26+] Annex A, insert alphabetically, "<> (1.2a) : A Fortran program executes as if it were replicated a number of times, the number of replications remaining fixed during execution of the program. Each copy is called an <> and each image executes asynchronously." <> (1.2a) : An integer value that identifies an image.". TR 19767: [432:12+] Annex A, after <> definition, insert new definition "<> (12.3.2.1) : The interface for a separate module procedure." 05-200r1: [434:26-27] Annex A, definition of <>, numbered list item (1), replace the whole item "Part ... component" with "subobject". NOTE TO EDITOR: Replace with "A subobject". TR 19767: [435:20+] Annex A, after <> definition, insert new definition "<> ({new refs 2.2.5, 11.2.2}) : A program unit that extends a module or another submodule.". 06-174r3: [436:1-] Annex A, insert alphabetically <> (1.2a) : A set of images formed by invoking the intrinsic collective subroutine FORM_TEAM (13.7.25l). <> (8.5.3) : Synchronization of the images in a team.". 06-174r3: [484:9+] Immediately before C.10 Section 15 notes, add new subclause "C.9a Section 13 notes C.9a.1 Module for THIS_IMAGE and IMAGE_INDEX The intrinsics THIS_IMAGE(CO_ARRAY) and IMAGE_INDEX(CO_ARRAY,SUB) cannot be written in Fortran since CO_ARRAY may be of any type and THIS_IMAGE(CO_ARRAY) needs to know the index of the image on which the code is running. As an example, here are simple versions that require the co-bounds to be specified as integer arrays and require the image index for THIS_IMAGE(CO_ARRAY). MODULE INDEX CONTAINS INTEGER FUNCTION IMAGE_INDEX(LBOUND,UBOUND,SUB) INTEGER,INTENT(IN) :: LBOUND(:),UBOUND(:),SUB(:) INTEGER :: I,N N = SIZE(SUB) IMAGE_INDEX = SUB(N) - LBOUND(N) DO I = N-1,1,-1 IMAGE_INDEX = IMAGE_INDEX*(UBOUND(I)-LBOUND(I)+1) + SUB(I) - LBOUND(I) END DO IMAGE_INDEX = IMAGE_INDEX + 1 END FUNCTION IMAGE_INDEX INTEGER FUNCTION THIS_IMAGE(LBOUND,UBOUND,ME) RESULT(SUB) INTEGER,INTENT(IN) :: LBOUND(:),UBOUND(:),ME INTEGER :: SUB(SIZE(LBOUND)) INTEGER :: EXTENT,I,M,ML,N N = SIZE(SUB) M = ME - 1 DO I = 1,N-1 EXTENT = UBOUND(I)-LBOUND(I)+1 ML = M M = M/EXTENT SUB(I) = ML - M*EXTENT + LBOUND(I) END DO SUB(N) = M + LBOUND(N) END FUNCTION THIS_IMAGE END MODULE INDEX C.9a.2 Collective co-array subroutine variations The subroutines of \ref{D13:Collective subroutines} return an array of the same shape as the given co-array after having applied an operation on the images involved. A note there shows how to program the operation being applied to all the elements of the co-array to produce a scalar result. Versions with other arguments can similarly be programmed, for example REAL FUNCTION GLOBAL_SUM_MASK(ARRAY,MASK) REAL :: ARRAY(:,:)[*],MASK(:,:) REAL,SAVE :: TEMP[*] TEMP = SUM(ARRAY,MASK=MASK) ! Sum on the executing image CALL CO_SUM(TEMP,GLOBAL_SUM_MASK) END FUNCTION GLOBAL_SUM_MASK FUNCTION GLOBAL_SUM(ARRAY,DIM) REAL :: ARRAY(:,:)[*] INTEGER :: DIM REAL,ALLOCATABLE :: GLOBAL_SUM(:) REAL,ALLOCATABLE :: TEMP(:)[:] ALLOCATE(GLOBAL_SUM(SIZE(ARRAY,3-DIM)) ) ALLOCATE( TEMP(SIZE(ARRAY,3-DIM))[*] ) TEMP = SUM(ARRAY,DIM) ! Sum on the executing image CALL CO_SUM(TEMP,GLOBAL_SUM) END FUNCTION GLOBAL_SUM". ===END OF DOCUMENT===