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