J3/06-175r2 Date: 12-may-2006 To: J3 From: Bill Long, Van Snyder Subject: Edits for BITS References: Feature J3-047, J3/05-188, J3/05-274r3 -------------------------------------------------------------- Following are a draft of the edits to implement the J3-047 feature, BITS type, as amended by paper J3/05-274r3. Note 1. < and > are used to delimit italic font. << and >> are used to delimit bold font. Note 2. All page and line numbers refer to j3/04-007. EDITS ..................................................................... [xiii] Introduction, the list of new Fortran 2008 features should include A BITS data type for non-numeric programming and enhanced handling of BOZ constants. ..................................................................... In section 1.6 Compatibility, retain paragraph 3:5-9 regarding new intrinsic procedure names. There are new intrinsics introduced in this proposal. In addition, add to a section on incompatibility with Fortran 2003: [3:10-] 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 will conflict with a user defined operator of the same name. ..................................................................... [15:39] Replace the second sentence of 2.4.1.1 Intrinsic type with: The intrinsic types are integer, real, complex, character, logical, and bits. ..................................................................... [16:2-3] Replace the end of the first sentence in the second paragraph of 2.4.1.1 Intrinsic types that begins with ", and the representation..." with: , the representation methods for the character and logical types (4.4.4, 4.4.5), and the number of bits for the bits type (4.4.6). ..................................................................... [26:28+] Add a new rule to '3.2.3 Operators' to make .XOR. a kind of : <> .XOR. ..................................................................... [33:5] At the end of the second paragraph of 'Section 4: Types', replace "character, and logical." with "character, logical, and bits." ..................................................................... [33:19] At the end of the second sentence of '4.1.1 Set of values', replace "character, and real." with: "character, real, and bits." ..................................................................... [35:29] In 4.4 Intrinsic types, replace the list of non-numeric types with: nonnumeric types: character, logical, and bits ..................................................................... [36:7+] Add a new type entry in 4.4 Intrinsic types, to R403 : <> BITS [] ..................................................................... [37:1-3] Delete R411 . [37:4-18] Move the rest of the description of constants out of 4.4.1 Integer type to new section 4.4.6 Bits type - edits [44:17+]. ..................................................................... [37:19,22-25] Delete some of the description of boz constants (replaced with new text in [44:17+]) and remove constraint C410 in '4.4.1 Integer type'. [37:20-21] Move this sentence into new 4.4.6 (see below). ..................................................................... [44:17+] Add a new subsection, consisting of: Firstly, the text: "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. 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). 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 the text from [37:4-18] here, renumbering the Rules from (R412, R413, R414, R415) to (R428b, R428c, R428d, R428e) and constraints (C408, C409) to (C423a C423b). | Insert a new rule after the text from [37:18]: | "R428f <> [ ] ... " Insert the text from [37:20-21] here. Insert more text and a Note: "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. Any bits value can be represented as a , or a concatenation of multiple s. The digits of octal constants represent triples of bits, and the hex digits of hexadecimal constants represent quartets of 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 kind assumed from the number of s or s in the constant, the constant is padded on the left (13.3) with enough 0 bits to create a constant of kind . If the specified has a value smaller than the kind assumed from the number of s or s in the constant, bits on the left are removed to create a constant of kind ." Note 4:15a: "Though the processor is required to provide bit kinds up to four times NUMERIC_STORAGE_SIZE, it is expected that the actual size limit is 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." [end Note] ..................................................................... [46:20] In 4.5.1.2 Sequence type, in the sentence defining a numeric sequence type, change "logical, or a numeric sequence type" "logical, default bits, or a numeric sequence type". ..................................................................... [76:5+] In '5.1.1.2 Class' in the discussion of type compatibility, add 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." ..................................................................... [76:7-9] In '5.1.1.2 Class', replace the paragraph defining TKR compatible 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. ..................................................................... [89:20-22] Delete this paragraph from '5.2.5 DATA statement', referring to in DATA statements. ..................................................................... [119:2] In '7.1.1.4 Level-3 expressions' replace "character operator " with "character operator and bits concatenation operator ". ..................................................................... [120:2] In '7.1.1.6 Level-5 expressions' replace "the logical operators" with "the logical and bits operators". ..................................................................... [120:12+] In '7.1.1.6 Level-5 expressions', extend rule R721 for to include .XOR.: <> .XOR. ..................................................................... [121:7+] In 'Table 7.1: Type of operands and results for intrinsic operators', 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 ..................................................................... [121:7+] In the Note at the bottom of 'Table 7.1: Type of operands and results for intrinsic operators', replace the first sentence with: "The symbols I, R, Z, C, L, and B stand for the types integer, real, complex, character, logical, and bits respectively." ..................................................................... [121:17-25] In '7.1.2 Intrinsic operations', replace the 5th and 6th paragraphs beginning "A <> is an 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. 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 where the is not //, the two operands may be of different types or different kind type parameters. If one operand, , is not of type bits, that operand is converted to a value of type bits and kind type parameter BITS_KIND() (see 13.7.15b) before the operation is performed. If the resulting operands have different kind type parameters, the operand with the smaller kind type parameter is converted to a bits value with the kind type parameter of the other - operand before the operation is performed. | 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. ..................................................................... [123:24+] In '7.1.4 Type, type parameters, and shape of an expression', add a syntax term for a bits expression: R728a <> C709a (R728a) shall be of type bits. ..................................................................... [124:24] In '7.1.4.2 Type, type parameters, and shape of the result of an expression', in item (2) for unary operators, change "real, complex, or logical" to "real, complex, logical, or bits" ..................................................................... [124:44+] In '7.1.4.2 Type, type parameters, and shape of the result of an expression', add a new item in the list after item 5: (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. For an expression where both operands are of type bits and is a bits intrinsic binary operator other than //, the kind type parameter of the expression is the maximum of the kind type parameters of the operands. For an expression where only one operand is of type bits and is a bits intrinsic binary operator other than //, the kind type parameter of the expression is the maximum of the kind type parameter of the operand of type bits and BITS_KIND() where is the other operand. ..................................................................... [124:46+] At the end of '7.1.4.2 Type, type parameters, and shape of the result of an expression', 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. ..................................................................... [125:41] In the list of a specification inquiry in '7.1.6 Specification expression', replace item (4) with: (4) the kind inquiry functions KIND and BITS_KIND, ..................................................................... [132:9+] Add a new subsection to '7.1.8 Evaluation of operations' just before '7.1.8.7 Evaluation of a defined operation': 7.1.8.6a 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. ..................................................................... [132:18] In the second sentence of '7.2 Interpretation of operations' replace "character, relational, and logical" with "character, relational, logical, and bits". ..................................................................... /EDIT NOTE TO EDITOR: FIX EXISTING EXECRABLE STYLE AT [135:1-4,9-12]. [135:22-] At the end of '7.2.3 Relational intrinsic operations', add two 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." ..................................................................... /EDIT NOTE TO EDITOR: .EQV. SHOULD PRECEDE .NEQV. IN THIS TABLE. [135:28+] In Table 7.5 in '7.2.4 Logical intrinsic operations' add a new row following the entry for .OR.: ".XOR. Logical nonequivalence .XOR. True if either or is true, but not both." ..................................................................... [136:2-] After Table 7.6 in '7.2.4 Logical intrinsic operations' add a new paragraph: The values for the logical intrinsic operation .XOR. are identical to those for .NEQV. . ..................................................................... [136:2-] At the end of section '7.2 Interpretation of operations', add a new subsection: "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. If one of the operands is not of type bits, or they are of unequal kind type, they are converted as described in 7.1.2 before the operation is performed. 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. ). ..................................................................... [136:5+] In 'Table 7.7 Categories of operations and relative precedence', in the column labeled "Category of operation" replace "Logical" with "Logical or Bits" four times. In the second to last row of the same table, replace ".EQV. or .NEQV." with ".XOR., .EQV., or .NEQV." ..................................................................... [139:2] In 'Table 7.8 Type conformance for the intrinsic assignment statement', modify the entries for integer, real, complex, and logical, and add an entry for bits as follows: Type of Type of integer integer, real, complex, bits real integer, real, complex, bits complex integer, real, complex, bits bits integer, real, complex, bits, logical logical logical, bits ..................................................................... | [139:6] In the paragraph following Table 7.8, before the last sentence, insert a new sentence: | "A <> is an intrinsic assignment statement for which either or is of | type bits." | ***Note to editor: If the edits from 05-278r2 are taken into | account, the new sentence becomes: | "A <> is an intrinsic assignment | statement for which either the assigned variable or is of type | bits." | ..................................................................... | [141:14-] In '7.4.1.3 Interpretation of intrinsic assignments' add | four new paragraphs and a Note (following Note 7.39): | "For a bits intrinsic assignment statement, the assigned 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 assigned variable according to the rules of Table | 7.9a. Table 7.9a: Bits conversion and the assignment statement | Type of assigned variable Value assigned bits BITS (, KIND = KIND()) integer INT (, KIND = KIND()) logical LOGICAL (, KIND = KIND()) real REAL (, KIND = KIND()) complex CMPLX (, KIND = KIND()) Note: The functions BITS, INT, LOGICAL, REAL, CMPLX, and KIND are the generic functions defined in 13.7." | 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] | ***Note to editor: If the edits in 05-278r2 are taken into account, | the initial paragraph and table of this edit becomes: | "For a bits intrinsic assignment statement, the assigned 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 assigned variable according to the rules of | Table 7.9a. | Table 7.9a: Bits conversion and the assignment statement | Type of the assigned variable Value assigned | bits BITS (, KIND = KIND()) | integer INT (, KIND = KIND()) | logical LOGICAL (, KIND = KIND()) | real REAL (, KIND = KIND()) | complex CMPLX (, KIND = KIND()) | Note: The functions BITS, INT, LOGICAL, REAL, CMPLX, and KIND | are the generic functions defined in 13.7." ..................................................................... [143:14] In C716 in section '7.4.2 Pointer assignment' replace the last phrase "and the corresponding kind type parameters shall be equal" to "and the corresponding kind type parameters shall be | equal, or and shall be bits compatible (5.1.1.2). ..................................................................... [144:21] In '7.4.2.1 Data pointer assignment' replace the end of the first sentence of the 4th paragraph "as the corresponding type parameters of , or and shall be bits compatible (5.1.1.2)." ..................................................................... [226:23] In '10.6 Data edit descriptors', in item (2) of the second numbered list, replace "numeric or logical variable" with "numeric, bits, or logical variable" ..................................................................... [226:29] In the paragraph immediately before '10.6.1 Numeric editing', replace "numeric, logical" with "numeric, bits, logical" ..................................................................... [226:31] Replace the name of subsection 10.6.1, "Numeric editing", with "Numeric and bits editing" ..................................................................... [226:33] In the first sentence of '10.6.1 Numeric editing', replace "integer, real, and complex" with "integer, real, complex, and bits" ..................................................................... [227:16 - 228:1] Remove the B, O, and Z edit descriptors from subsubsection 10.6.1.1 Integer editing, resulting in: 10.6.1.1 Integer editing The I and I edit descriptors indicate that the field to be edited occupies positions, except when is zero. When is zero, the processor selects the field width. On input, shall not be zero. The specified input/output list item shall be of type integer or bits. The G edit descriptor (10.6.4.4) or the B, O, or Z edit descriptors (10.6.1.3) also can be used to edit integer data. If the input list item is of type bits, the input field is edited as if the input list item were of type integer and bits compatible with the actual list item, followed by the effect of an intrinsic assignment of the resulting integer value to the actual list item. On input, m has no effect. In the input field for the I edit descriptor, the character string shall be an (R406), except for the interpretation of blanks. If the output list item is of type bits, its value is interpreted as a nonnegative integer (13.3). The output field for the I edit descriptor consists of zero or more leading blanks followed by a minus sign if the internal value is negative, or an optional plus sign, followed by the magnitude of the internal value as a without leading zeros. Note 10.8 The always consists of at least one digit. [end Note] The output field for the I edit descriptor is the same as for the I edit descriptor, except that the consists of at least digits. If necessary, sufficient leading zeros are included to achieve the minimum of digits. The value of shall not exceed the value of , except when is zero. If is zero and the internal value consists of all zero bits, the output field | consists of only blank characters, regardless of the sign control in | effect. When and are both zero, and the internal value is | zero, one blank character is produced. ..................................................................... [228:5] At the end of the first paragraph in '10.6.1.2 Real and complex editing', add a new sentence: The B, O, and Z edit descriptors also can be used to edit real data (10.6.1.3). ..................................................................... [232:21-] Before '10.6.2 Logical editing' add a new subsubsection to the Numeric editing subsection: 10.6.1.3 Bits editing The B, B, O, O, Z, and Z edit descriptors indicate that the field to be edited occupies positions, except when is zero. When is zero, the processor selects the field | width. On input, shall not be zero. The input/output list item shall be of type bits, integer, or real. The G edit descriptor (10.6.4.4) or the I edit descriptor (10.6.1.1) also can be used to edit bits data. If the input list item is not of type bits, the input field is edited as if the input list item were of type bits and bits compatible with the actual list item, followed by the effect of an intrinsic assignment of the resulting bits value to the actual list item. On input, m has no effect. In the input field for the B, O, and Z edit descriptors the character string shall consist of binary, octal, or hexadecimal digits (as in | R428c, R428d, R428e) in the respective input field. The lower-case | hexadecimal digits a through f in a hexadecimal input field are | equivalent to the corresponding upper-case hexadecimal digits. If the output list item is not of type bits, it is first converted to a list item of type bits that is bits compatible with it. The output field for the B, O, and Z descriptors consists of zero or more leading blanks followed by the internal value in a form identical to the digits of a binary, octal, or hexadecimal constant, respectively, with the same value and without leading zeros. Note 10.13a A binary, octal, or hexadecimal constant always consists of at least one digit or hexadecimal digit. [end Note] The output field for the B, O, and Z edit descriptor is the same as for the B, O, and Z edit descriptor, except that the or consists of at least digits. If necessary, sufficient leading zeros are included to achieve the minimum of digits. The value of shall not exceed the value of , except when is zero. If is zero and the internal value consists of all zero bits, the output field consists of only blank characters. When and are both zero, and the internal value consists of all zero bits, one blank character is produced. ..................................................................... [233:23] In '10.6.4 Generalized editing', last sentence of the first paragraph, replace "integer, logical, or character" with | "integer, bits, logical, or character". ..................................................................... | [234:13-] Before subsection '10.6.4.3 Generalized logical editing', | add a new subsection: | 10.6.4.1a Generalized bits editing When used to specify the input/output of bits data, the G and GE edit descriptors follow the rules for the Zw edit descriptor (10.6.1.3), except that shall not be zero. When used to specify the output of bits data, the G0 edit descriptor follows the rules for the Z0 edit descriptor. ..................................................................... [237:37] In the first sentence of the second paragraph of '10.7.6 BN and BZ editing', replace "in numeric input fields" with "in | numeric and bits input fields". ..................................................................... [237:42-43] Replace the first sentence of the third paragraph of '10.7.6 BN and BZ editing' with: The blank interpretation mode affects only numeric and bits editing (10.6.1), generalized numeric editing (10.6.4.1), and generalized bits editing (10.6.4.4) on input. ..................................................................... | [239:19+] After the third paragraph of '10.9.1 List-directed input', | which begins 'Then the next effective item is of type integer', add | a new paragraph: | When the next effective item is of type bits, the value on the input record is interpreted as if a Z edit descriptor with a suitable value of were used. ..................................................................... | [241:10+] After the fourth paragraph of '10.9.2 List-directed output' | that begins 'Integer output' add a new paragraph: Bits output constants are produced with the effect of a Z edit | descriptor. ..................................................................... | [241:15-16] In the sixth paragraph of '10.9.2 List-directed output' | that begins 'For numeric output', replace "numeric" with | "numeric and bits" twice. ..................................................................... [243:36] In the first sentence of '10.10.1.2' Namelist input values' replace "list items of types logical, integer, and character" with | "list items of types logical, integer, bits, and character". ..................................................................... | [244:37+] After the fourth paragraph of '10.10.1.3 Namelist group | object list items' that begins 'When the next effective item is | of type integer', add a new paragraph: When the next effective list item is of type bits, the value in the input record is interpreted as if a Z edit descriptor with a suitable value of were used. ..................................................................... | [246:14+] After the second paragraph of '10.10.2.1 Namelist output | editing', that begins 'Integer output', add a new paragraph: Bits output constants are produced with the effect of a Z edit | descriptor. | ..................................................................... | [247:2-3] In the fourth paragraph of '10.10.2.1 Namelist output | editing' that begins 'For numeric output', replace "numeric" with | "numeric and bits" twice. ..................................................................... [268:21] In the first sentence of '12.4.1.2 Actual arguments associated with dummy data objects', replace "it shall be type compatible (5.1.1.2) with" with "it shall be type compatible or bits compatible (5.1.1.2) with". ..................................................................... [269:1] Replace the beginning of the first sentence of the second paragraph of '12.4.1.2 Actual arguments associated with dummy data objects' "The type parameter values" with "Unless the actual argument and the corresponding dummy argument are bits compatible, the type parameter values" | ..................................................................... | [269:15] In the sixth paragraph of '12.4.1.2 Actual arguments | associated with dummy data objects' replace the end of the first | sentence in this paragraph "and the nondeferred type parameters and | ranks shall agree" with ", the ranks shall agree and either the | nondeferred type parameters shall agree or or the actual argument and | the dummy argument shall be bits compatible" | ***Note to editor: When combined with the effects of edit [269:14] | from 06-108r1, the whole first sentence reads: | "If the dummy argument and the actual argument are pointers, the | ranks shall agree and either the nondeferred type parameters shall | agree or the actual argument and the dummy argument shall be bits | compatible." | ..................................................................... | [269:16] In the sixth paragraph of '12.4.1.2 Actual arguments | associated with dummy data objects' replace the end of the second | sentence in this paragraph "and the nondeferred type parameters and | ranks shall agree" with ", the ranks shall agree, and either the | nondeferred type parameters shall agree or the actual argument and | the dummy argument shall be bits compatible" ..................................................................... [292:20-24] Replace the first paragraph of '13.3 Bit model' with: The bit manipulation procedures are 23 elemental functions and one elemental subroutine. Logical operations on bits are provided by the elemental functions IOR, IAND, NOT, IEOR, and MERGE_BITS, and the transformational functions IALL, IANY, and IPARITY; shift operations are provided by the elemental functions ISHFT, ISHFTC, SHIFTA, SHIFTL, SHIFTR, DSHIFTL, and DSHIFTR; bit subfields can be referenced by the elemental function IBITS and by the elemental subroutine MVBITS; single-bit processing is provided by the elemental functions BTEST, IBSET, and IBCLR; characterization of | bit sequences is provided by the elemental functions POPCNT, POPPAR, LEADZ, and TRAILZ. ..................................................................... [292:25] In the first sentence of the second paragraph of '13.3 Bit model' replace "a bit is defined to be" with: a bit in the bit model for an integer is defined to be ..................................................................... [292:28+] Add a new paragraph following the second paragraph of '13.3 Bit model': Using the notation of the formula above, the value of a bits object | of kind is represented as the ordered sequence of bits with the bit at position . The rightmost bit is and the leftmost bit is . Such a bits object can be interpreted as a nonnegative integer with the value . ..................................................................... [295:29-] In the list of '13.5.4 Kind functions' add a new entry: | BITS_KIND(X [, KIND]) Bits kind type parameter value compatible with the argument ..................................................................... [295:29+] In the list of '13.5.4 Kind functions' add a new entry: | SELECTED_BITS_KIND(N) Bits kind type parameter value, given | number of bits ..................................................................... [295:36-] In the list of '13.5.5 Miscellaneous type conversion functions' add a new entry: | BITS(A [,KIND]) Conversion to bits type ..................................................................... [296:20-31] In the list of '13.5.9 Bit manipulation procedures', add the following at the correct alphabetical locations: DSHIFTL (I, J, SHIFT) Double left shift DSHIFTR (I, J, SHIFT) Double right shift MERGE_BITS (I, J, MASK) Merge bits under mask SHIFTA (I, SHIFT) Arithmetic right shift SHIFTL (I, SHIFT) Left shift SHIFTR (I, SHIFT) Right shift ..................................................................... [296:31+] After '13.5.9 Bit manipulation procedures', add two new subsections: 13.5.9a Bit characterization functions LEADZ (I [,KIND]) Number of leading zero bits POPCNT (I [,KIND]) Number of one bits POPPAR (I [,KIND]) Parity of one bits TRAILZ (I [,KIND]) Number of trailing zero bits 13.5.9b Bit construction functions MASKL (I [,KIND]) Left justified bit mask MASKR (I [,KIND]) Right justified bit mask ..................................................................... [297:4-11] In the list of '13.5.12 Array reduction functions', add the following at the correct alphabetical locations: IALL (ARRAY, DIM [,MASK]) or Bitwise AND of array elements IALL (ARRAY [,MASK]) IANY (ARRAY, DIM [,MASK]) or Bitwise OR of array elements IANY (ARRAY [,MASK]) IPARITY (ARRAY, DIM, [,MASK]) or Bitwise exclusive OR of array elements IPARITY (ARRAY [,MASK]) PARITY (MASK [,DIM]) True if an odd number of values is true ..................................................................... Modify the description of the ACHAR function (13.7.2): [300:29] Change the description of the argument I to: "shall be of type integer or bits. If I is of type bits, it is | interpreted as a nonnegative integer as described in 13.3. [301:6] Append to the current Example text: ACHAR(z'41') has the value 'A'. ..................................................................... | ***Note to editor: This edit follows the edit for BESSEL_YN from | paper 05-268r3 at [306:13+]. | [306:13+] Add two new intrinsic functions, BITS and BITS_KIND: "13.7.15a BITS (A [, KIND]) <> Convert to bits type. <> Elemental function. <> A shall be of type integer, real, complex, logical, or bits. | KIND (optional) shall be a scalar integer initialization | expression. <> Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default bits type. <> If A is of type bits and the kind type parameter of A is the same as | that of the result, the result value is the value of A. | If A is of type bits with a smaller kind type parameter value than | that of the result, the rightmost KIND(A) bits of the result value | are the same as those of A and the remaining bits of the result are | 0. If A is of type bits with a larger kind type parameter value than | that of the result, the result value consists of the rightmost | KIND(result) bits of A. | If A is not of type bits and has a storage size greater than or | equal to the kind type parameter of the result, the result value | consists of the rightmost KIND(result) bits of the internal | representation of A. | If A is not of type bits and has a storage size less than or equal | to the kind type parameter of the result, the rightmost bits of the | result are those of the internal representation of A and the | remaining bits of the result are 0. <> BITS(z"abcd",32) has the value z"0000abcd". BITS(-1) has the value z"ffffffff" for an implementation where the default integer representation is 32-bit two's-complement. BITS(.true.,5) has the value b"00001" for an implementation that represents the logical value true by setting the low order bit of the internal value and clearing the other bits. BITS(X) has the value z"7f800000" if the value of X is an IEEE 32-bit positive infinity and default bits kind is 32." | 13.7.15b BITS_KIND (X [, KIND]) | <> Return bits kind compatible with the argument. | <> Inquiry function. | <> | X Shall be of type bits, integer, real, complex, or | logical. | KIND (optional) shall be a scalar integer initialization | expression. | <> Scalar integer. If KIND is present, the kind type | parameter is that specified by the value of KIND; otherwise, the | kind type parameter is that of default integer type. | <> If X is of type bits, the result value is | KIND(X). If X is of type default integer, default real, or default | logical, the result value is NUMERIC_STORAGE_SIZE (13.8.2.7). If | X is of type double precision or default complex, the result is | 2*NUMERIC_STORAGE_SIZE. If X is of type complex with the same | kind type parameter as that of double precision, the result value | is 4*NUMERIC_STORAGE_SIZE. If X is of type non-default integer, | the result value is BIT_SIZE(X). If X is of a non-default logical | or non-default non-integer numeric type, the result value is the | number of bits of storage used by the processor to represent | scalar objects of that type and kind. | <> The value of BITS_KIND(0) is 32 if the value | of NUMERIC_STORAGE_SIZE is 32. ..................................................................... [306:14-21] Replace the definition of BIT_SIZE (13.7.16): "13.7.16 BIT_SIZE(I [, KIND]) <> Returns the number of bits. <> Inquiry function. <> I shall be of type integer or bits. It may be a scalar or an array. | KIND (optional) shall be a scalar integer initialization | expression. | <> Scalar integer. If KIND is present, the kind | type parameter is that specified by the value of KIND. If KIND is | not present and I is of type integer the result is a scalar integer | with the same kind type parameter as I. If KIND is not present and I | is of type bits, the result is a scalar of type default integer. <> If I is of type integer, the result has the value of the number of bits of the model integer defined for bit manipulation contexts in 13.3. If I is of type bits, the result value is KIND(I). | <> BIT_SIZE(1) has the value 32 if of the model is | 32. BIT_SIZE(z"ffff") has the value 16." /EDIT NOTE: "if of the model is" UGH. [Note on /EDIT NOTE: This is the existing text in 04-007.] ..................................................................... Modify the definition of BTEST (13.7.17) | [306:23] Change the Description to: Tests a bit of an integer or | bits value." [306:26] Change the description of the I argument to: "shall be of type integer or bits." | [306:32] Insert after the first example in the current Example text: BTEST(b"01000",3) has the value true. ..................................................................... Modify the definition of CHAR (13.7.19) [307:17] Change the description of the argument I to: shall be of type integer or bits. If I is of type bits, it is interpreted as a non-negative integer as described in 13.3. The value of I shall be in the range 0 <= I <= -1, where is the number of characters in the collating sequence associated with the specified kind type parameter. | [307:26] Replace "Example" by "Examples" and append: CHAR(z'41') has the value 'A' on a processor using the ASCII collating sequence. - ..................................................................... Modify the definition of CMPLX (13.7.20) [307:31] In the descrption of the X argument, replace "or complex, or a with "complex, or bits". | [308:1] In the description of the Y argument, replace "integer or real, or a " with "integer, real, or bits". ..................................................................... Modify the definition of CO_MAXLOC (13.7.25d) in feature UK-001. ***Note to editor: This edit is a modification of the edits for [309:32+] in the paper for co-arrays, UK-001. [309:32+] In the description of the ARRAY argument for the CO_MAXLOC function, replace "of type integer, real, or character" with "of type integer, real, bits, or character". ..................................................................... Modify the definition of CO_MAXVAL (13.7.25e) in feature UK-001. ***Note to editor: This edit is a modification of the edits for [309:32+] in the paper for co-arrays, UK-001. [309:32+] In the description of the ARRAY argument for the CO_MAXVAL function, replace "of type integer, real, or character" with "of type integer, real, bits, or character". ..................................................................... Modify the definition of CO_MINLOC (13.7.25f) in feature UK-001. ***Note to editor: This edit is a modification of the edits for [309:32+] in the paper for co-arrays, UK-001. [309:32+] In the description of the ARRAY argument for the CO_MINLOC function, replace "of type integer, real, or character" with "of type integer, real, bits, or character". ..................................................................... Modify the definition of CO_MINVAL (13.7.25g) in feature UK-001. ***Note to editor: This edit is a modification of the edits for [309:32+] in the paper for co-arrays, UK-001. [309:32+] In the description of the ARRAY argument for the CO_MINVAL function, replace "of type integer, real, or character" with "of type integer, real, bits, or character". ..................................................................... Modify the definition of DBLE (13.7.29) [312:21] In the description of the argument A, replace "or complex or a " with "complex, or bits". ..................................................................... [314:11+] Add two new intrinsic functions, DSHIFTL and DSHIFTR: "13.7.33a DSHIFTL (I, J, SHIFT) <> Performs a double left shift. <> Elemental function. <> I shall be of type integer or bits. J shall be of the same type and kind as I. | SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The result has the value IOR(SHIFTL(I,SHIFT), SHIFTR(J, BIT_SIZE(J)-SHIFT)). DSHIFTL(I,I,SHIFT) has the same result value as ISHFTC(I,SHIFT). <> DSHIFTL(z"01234567", z"89abcdef", 8) has the value z"23456789"." "13.7.33b DSHIFTR (I, J, SHIFT) <> Performs a double right shift. <> Elemental function. <> I shall be of type integer or bits. J shall be of the same type and kind as I. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The result has the value IOR(SHIFTL(I, BIT_SIZE(I)-SHIFT), SHIFTR(J, SHIFT)). DSHIFTR(I,I,SHIFT) has the same result value as ISHFTC(I,-SHIFT). <> DSHIFTR(z"01234567", z"89abcdef", 8) has the result z"6789abcd". ..................................................................... Modify the definition of HUGE (13.7.44) [319:11-12] In the Description, replace "number" with "value" and "numbers" with "values". [319:14] In the Argument, replace "of type integer or real" with "of type integer, real, or bits". [319:18] Add a new sentence at the end of the Result Value: "If X is of type bits, the result value has all of its bits set to 1." ..................................................................... [320:14+] Add a new intrinsic function, IALL: "13.7.45a IALL (ARRAY ,DIM [, MASK]) or IALL (ARRAY, [MASK] ) "<> Bitwise AND of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK." "<> Transformational function. <> ARRAY shall be of type integer or bits. It shall not be scalar. | DIM (optional) shall be a scalar of type integer with a value in the range 1 <= DIM <= where is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. <> The result is of the same type and kind type parameter as ARRAY. It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of ARRAY. <>" | ": The result of IALL(ARRAY) has a value equal to the | bitwise AND of all the elements of ARRAY. If ARRAY | has size zero the result value is equal to | NOT(INT(0,KIND(ARRAY))) if ARRAY is of type integer, | and NOT(BITS(b'0',KIND(ARRAY))) otherwise. | ": The result of IALL(ARRAY, MASK=MASK) has a value | equal to IALL(PACK(ARRAY, MASK)). | : The result of IALL(ARRAY, DIM=DIM [,MASK=MASK]) | has a value equal to that of | IALL(ARRAY, [, MASK=MASK] if ARRAY has rank one. Otherwise, the value of element () | of the result is equal to IALL(ARRAY() [,MASK = MASK(s_1, s_2, ..., s_{DIM-1},:, s_{DIM+1}, ..., s_n>]) - <> IALL( [b"1110", b"1101", b"1011"] ) has the value b"1000". IALL( [b"1110", b"1101", b"1011"], MASK=[.true.,.false.,.true]) has the value b"1010". IALL( [14, 13, 11] ) has the value 8. IALL( [14, 13, 11], MASK=[.true.,.false.,.true]) has the value 10. ..................................................................... Modify the description of the IAND function (13.7.46): [320:18-21] Replace the Arguments and Result Characteristics section with: "<> I shall be of type integer or bits. J shall be of type integer or bits. BITS_KIND(I) shall be equal to BITS_KIND(J). <> If I and J have the same type, the result characteristics are those of I. Otherwise, the result characteristics are those of the argument with integer type." [320:25] Replace "Example" with "Examples" and append: IAND(z"12345678", z"0000ffff") has the value z"00005678". ..................................................................... [320:25+] Add a new intrinsic function, IANY: "13.7.46a IANY (ARRAY ,DIM [, MASK]) or IANY (ARRAY, [MASK] ) <> Bitwise OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK." <> Transformational function. <> ARRAY shall be of type integer or bits. It shall not be scalar. DIM (optional) shall be a scalar and of type integer with a value in the range 1 <= DIM <= where is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. <> The result is of the same type and kind type parameter as ARRAY. It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of ARRAY. <> : The result of IANY(ARRAY) is the bitwise OR of all the elements of ARRAY. If ARRAY has size zero the | result value is equal to zero if ARRAY is of type | integer, and BITS(b'0',KIND(ARRAY)) otherwise. | : The result of IANY(ARRAY, MASK=MASK) has a value | equal to IANY(PACK(ARRAY, MASK)). - | : The result of IANY(ARRAY, DIM=DIM [,MASK=MASK]) | has a value equal to that of | IANY(ARRAY, [, MASK=MASK] if ARRAY has rank one. | Otherwise, the value of element () of the result is equal to | IANY(ARRAY() [,MASK = MASK(s_1, s_2, ..., s_{DIM-1},:, s_{DIM+1}, ..., s_n>]) - <> IANY( [b"1110", b"1101", b"1000"] ) has the value b"1111". IANY( [b"1110", b"1101", b"1000"], MASK=[.true.,.false.,.true]) has the value b"1110". IANY( [14, 13, 8] ) has the value 15. IANY( [14, 13, 8], MASK=[.true.,.false.,.true]) has the value 14. ..................................................................... Modify the description of IBCLR (13.7.47): [320:30] Replace the description of the argument I with "shall be of type integer or bits". [321:6] Append to the current Examples text: IBCLR(b"11111",3) has the value b"10111". ..................................................................... Modify the description of IBITS (13.7.48): [321:11] Replace the description of the argument I with "shall be of type integer or bits". | [321:18] Pluralize "Example" and append to the current Examples text: IBITS(z"abcd",4,8) has the value z"00bc". ..................................................................... Modify the description of IBSET (13.7.49): [321:23] Replace the description of the argument I with "shall be of type integer or bits". [321:29] Append to the current Examples text: IBSET(b"00000",3) has the value b"01000". ..................................................................... Modify the description of the IEOR function (13.7.51): [322:16-19] Replace the Arguments and Result Characteristics sections with: <> I shall be of type integer or bits. | J shall be of type integer or bits. BITS_KIND(I) shall be | equal to BITS_KIND(J). <> If I and J have the same type, the result characteristics are those of I. Otherwise, the result characteristics are those of the argument with integer type. [322:23] Replace "Example" with "Examples" and append: IEOR(z"12340000", z"1234ffff") has the value z"0000ffff". ..................................................................... Modify the definition of INT (13.7.53) [323:21] In the description of the A argument, replace "or complex, or a ." with "complex, or bits." [323:31-33] Replace Result Value Case (iv) with: If A is of type bits, the result value is that with which I becomes defined as a result of the intrinsic assignment I = A, for an integer | variable I with the kind type parameter of the result. ..................................................................... Modify the description of the IOR function (13.7.54): [323:38-324:3] Replace the Arguments and Result Characteristics sections with: <> I shall be of type integer or bits. | J shall be of type integer or bits. BITS_KIND(I) shall be | equal to BITS_KIND(J). <> If I and J have the same type, the result characteristics are those of I. Otherwise, the result characteristics are those of the argument with integer type. [324:7] Replace "Example" with "Examples" and append: | IOR(z"12345678", z"0000ffff") has the value z"1234ffff". ..................................................................... [324:7+] Add a new intrinsic function, IPARITY: 13.7.54a IPARITY (ARRAY ,DIM [, MASK]) or IPARITY (ARRAY, [MASK] ) <> Bitwise exclusive OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. <> Transformational function. <> ARRAY shall be of type integer or bits. It shall not be scalar. DIM (optional) shall be a scalar and of type integer with a value in the range 1 <= DIM <= where is the rank of ARRAY. The corresponding actual argument shall not be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. <> The result is of the same type and kind type parameter as ARRAY. It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of ARRAY. <> - : The result of IPARITY(ARRAY) is the bitwise exclusive OR of all the elements of ARRAY. If ARRAY has size zero the | result value is equal to zero if ARRAY is of type | integer, and BITS(b'0',KIND(ARRAY)) otherwise. | : The result of IPARITY(ARRAY, MASK=MASK) has a value equal to | IPARITY(PACK(ARRAY, MASK)). | : The result of IPARITY(ARRAY, DIM=DIM [,MASK=MASK]) | has a value equal to that of | IPARITY(ARRAY, [, MASK=MASK] if ARRAY has rank one. | Otherwise, the value of | element () of the result is equal to IPARITY(ARRAY() [,MASK = MASK(s_1, s_2, ..., s_{DIM-1},:, s_{DIM+1}, ..., s_n>]) - <> IPARITY( [b"1110", b"1101", b"1000"] ) has the value b"1011". IPARITY( [b"1110", b"1101", b"1000"], MASK=[.true.,.false.,.true]) has the value b"0110". IPARITY( [14, 13, 8] ) has the value 11. IPARITY( [14, 13, 8], MASK=[.true.,.false.,.true]) has the value 6. ..................................................................... Modify the definition of ISHFT (13.7.55) [324:12] Replace the description of the I argument with "shall be of type integer or bits." | [324:20] Pluralize "Example" and append to the current example text: ISHFT (b"00000011",1) has the value b"00000110". ..................................................................... Modify the definition of ISHFTC (13.7.56) [324:25] Replace the description of the I argument with "shall be of type integer or bits." | [325:7] Pluralize "Example" and append to the current example text: ISHFTC (z"abcd",4,8) has the value z"abdc". ..................................................................... [326:16+] Add a new intrinsic function, LEADZ: 13.7.60a LEADZ (I [,KIND]) <> Count the number of leading zero bits. <> Elemental function. <> I shall be of type integer or bits. | KIND (optional) shall be a scalar integer initialization | expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. <> If all of the bits of I are zero, the result value | is BIT_SIZE(I). Otherwise, the result value is BIT_SIZE(I)-1 minus the position of the leftmost 1 bit in I, where the rightmost bit position is 0. The model for the interpretation of an integer value as a sequence of bits is in 13.3. <> LEADZ(b"001101000") has the value 2. LEADZ(1) has the value 31 if BIT_SIZE(1) has the value 32. ..................................................................... Modify the definition of LOGICAL (13.7.69) [329:23] Replace the Description text with: Converts between kinds of logical or from bits to logical. [329:26] In the description of the L argument, replace "of type logical" with "of type logical or bits". | [329:30] Replace the Result Value text with: "If L is of type logical, the result value is that of L. If L is of type bits and KIND(L) is greater than or equal to | BITS_KIND(result), the result has the value whose internal representation is the same as the rightmost bits of L. | If L is of type bits and KIND(L) is less than BITS_KIND(result), | the rightmost KIND(L) bits of the internal representation of the | result value are the same as those of L, and the remaining bits of | the result are zero." | NOTE FOR LATER POLISHING: THIS DESCRIPTION BEGS FOR AN EXAMPLE. ..................................................................... [330:1+] Add two new intrinsic functions, MASKL and MASKR: 13.7.69a MASKL (I, [,KIND]) <> Generate a left justified mask. | <> Elemental function. <> I shall be of type integer. It shall be nonnegative and less than or equal to the kind type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. <> Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default bits type. <> The result value has its leftmost I bits set to 1 and the remaining bits set to 0. <> MASKL(12) has the value z"fff00000" if the default bits kind type parameter value is 32. 13.7.69b MASKR (I, [,KIND]) <> Generate a right justified mask. | <> Elemental function. <> I shall be of type integer. It shall be nonnegative and less than or equal to the kind type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. <> Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default bits type. <> The result value has its rightmost I bits set to 1 and the remaining bits set to 0. <> MASKR(12) has the value z"00000fff" if the default bits kind type parameter value is 32. ..................................................................... Modify the definition of MAX (13.7.71) [331:6] In the description of the Arguments, replace "integer, real, or" with "integer, real, bits, or" [331:17+] Append to the end of the current Examples text: MAX(b"10000",b"01111") has the value b"10000". ..................................................................... Modify the definition of MAXLOC (13.7.73) [331:32] In the description of the ARRAY Argument, replace "integer, real, or" with "integer, real, bits, or" ..................................................................... Modify the definition of MAXVAL (13.7.74) [333:2] In the description of the ARRAY Argument, replace "integer, real, or" with "integer, real, bits, or" ..................................................................... [334:7+] Add a new intrinsic function, MERGE_BITS: 13.7.75a MERGE_BITS (I, J, MASK) <> Merge bits under mask. <> Elemental function. <> I shall be of type bits or integer. J shall have the same type and type parameters as I. | MASK shall be of type bits. KIND(MASK) shall be equal to | BITS_KIND(I). <> Same as I. | <> The result has the value of IOR(IAND(I,MASK), IAND(J,NOT(MASK))). <> MERGE_BITS(z"01234567",z"89abcdef",z"ffff0000") has the value z"0123cdef". ..................................................................... Modify the definition of MIN (13.7.76) [334:11] In the description of the Arguments, replace "integer, real, or" with "integer, real, bits, or" | [334:22+] Append to the end of the current Examples text: MIN(b"10000",b"01111") has the value b"01111". ..................................................................... Modify the definition of MINLOC (13.7.78) [335:3] In the description of the ARRAY Argument, replace "integer, real, or" with "integer, real, bits, or" ..................................................................... Modify the definition of MINVAL (13.7.79) [336:9] In the description of the ARRAY Argument, replace "integer, real, or" with "integer, real, bits, or" ..................................................................... Modify the definition of MVBITS (13.7.83) [338:26] In the description of the FROM argument, replace "shall be of type integer." with "shall be of type integer or bits." [339:1] In the first 2 lines of the description of the TO argument, replace "shall be a variable of type integer with the same kind type parameter value as FROM" with "shall be a variable with the same type and kind type parameter value as FROM" | [339:4] Pluralize "Example" and append to the end of the current | example text: If TO has the initial value b"000000111111", the value of TO after the statement CALL MVBITS(b"000000000011", 0, 2, TO, 8) is b"001100111111". ..................................................................... Modify the definition of NOT (13.7.87): [340:20] Replace the Argument description with: I shall be of type integer or bits. [340:22] Replace "The result is" at the beginning of the Result Value description with: "If I is of type integer, the result value is" [340:24] After the last sentence of the Result Value description, add a new sentence: "If I is of type bits, the result value is (.NOT. I)." | [340:26] Pluralize "Example". At the end of the Example text, | add a new sentence: "NOT(z"ffff0000") has the value z"0000ffff".". ..................................................................... [342:16+] Add three new intrinsic functions, PARITY, POPCNT, and POPPAR: 13.7.89a PARITY (MASK [,DIM]) <> Determine whether an odd number of values are true in MASK along dimension DIM. <> Transformational function. <> MASK shall be of type logical. It shall not be scalar. DIM (optional) shall be a scalar and of type integer with a value in the range 1 <= DIM <= where is the rank of MASK. The corresponding actual argument shall not be an optional dummy argument. <> The result is of type logical with the same kind type parameter as MASK. It is scalar if DIM is absent or if MASK has rank one; otherwise, the result is an array of rank - 1 and shape () where () is the shape of MASK. <> : The result of PARITY(MASK) has the value true if an odd number of the elements of MASK are true, and false otherwise. : If MASK has rank one, PARITY(MASK,DIM) has a value equal to that of PARITY(MASK). Otherwise, the value of element () of PARITY(MASK,DIM) is equal to PARITY(MASK()) <> : The value of PARITY([T,T,T,F]) is true if T has the value true and F has the value false. | T T F | : If B is the array | T T T |, where T has the value true | and F has the value false, then PARITY(B,DIM=1) is | [F, F, T] and PARITY(B, DIM=2) is [F, T]. 13.7.89b POPCNT (I [,KIND]) <> Return the number of one bits. <> Elemental function. <> I shall be of type integer or bits. | KIND (optional) shall be a scalar integer initialization | expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of the default integer type. <> If I is of type integer, the result value is the number of one bits in the sequence of bits of I. The model for the interpretation of an integer value as a sequence of bits is in 13.3. If I is of type bits, the result value is the number of one bits in I. <> POPCNT([1,2,3,4,5,6]) has the value [1,1,2,1,2,2]. POPCNT(z"ffff0000") has the value 16. If B is of type bits, POPCNT(HUGE(B)) has the same value as KIND(B). 13.7.89c POPPAR (I [,KIND]) | <> Return the bitwise parity. <> Elemental function. <> I shall be of type integer or bits. | KIND (optional) shall be a scalar integer initialization | expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of the default integer type. <> POPPAR(I) has the value 1 if POPCNT(I) is odd, and 0 of POPCNT(I) is even. <> POPPAR([1,2,3,4,5,6]) has the value [1,1,0,1,0,0]. POPPAR(z"ffff0000") has the value 0. ..................................................................... Modify the definition of RANDOM_NUMBER (13.7.94) as: [344:8-9] Replace the Desciption text with: Returns one pseudorandom value or an array of pseudorandom values. [344:11-13] Replace the Argument text with: HARVEST shall be of type real or bits. It is an INTENT(OUT) argument. It may be a scalar or an array variable. If it is of type real, it is assigned pseudorandom numbers from a uniform distribution in the interval 0 <= < 1. If it is of type bits, it is assigned pseudorandom values with each of the KIND(HARVEST) bits of each value having a probability of approximately 0.5 of being 1. [344:15+] Add a new statement to the example code: BITS B [344:19+] Add a new statement and comment to the example code: CALL RANDOM_NUMBER(B) ! B contains a uniformly random collection of 0 and 1 bits. ..................................................................... Modify the definition of REAL (13.7.97): [346:1] In the description of the A argument, replace "or complex, or a ." with "complex, or bits." [346:5-6] In Case (i) of the Result Characteristics, replace "If A is of type integer or real" with "If A is of type integer, real, or bits" twice. [346:11-13] Delete all of Result Characteristics Case (iii). | [346:16] Add two new sentences to the end of Result Value Case (i): If A is of type bits and KIND(A) is greater than or equal to BITS_KIND(result), the result has the value whose internal representation is the same as the rightmost bits of A. If A is of type bits and KIND(A) is less than BITS_KIND(result), | the rightmost KIND(A) bits of the internal representation of the | result value are the same as those of A, and the remaining bits of | the result are zero." [346:19-22] Delete all of Result Value Case (iii). | [346:24] Append a new sentence to the examples: | REAL(z"7f800000") has the value positive infinity if the default | real kind is an IEEE single precision. ..................................................................... [349:6+] Add a new intrinsic function, SELECTED_BITS_KIND: 13.7.103a SELECTED_BITS_KIND (N) <> Returns a value of the kind type parameter of a bits type with N bits. <> Transformational function. <> N shall be scalar and of type integer. <> Default integer scalar. <> The result value is N if the processor supports a bits type with a kind type parameter equal to N; otherwise the result value is -1. <> If the NUMERIC_STORAGE_SIZE value for the processor is 32, SELECT_BITS_KIND(43) has the value 43. ..................................................................... [351:19+] Add three new intrinsic functions, SHIFTA, SHIFTL, and SHIFTR: 13.7.108a SHIFTA (I, SHIFT) <> Performs an arithmetic right shift. <> Elemental function. <> I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The result has the value obtained by shifting the bits of I to the right SHIFT bits and replicating the leftmost bit of I in the left SHIFT bits. If SHIFT is zero the result is I. Bits shifted out from the right are lost. The model for the interpretation of an integer value as a sequence of bits is in 13.3. <> SHIFTA(b"10000",2) has the value b"11100". 13.7.108b SHIFTL (I, SHIFT) <> Performs a left shift. <> Elemental function. <> I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The value of the result is ISHFT(I,SHIFT). <> SHIFTL(3,1) has the value 6. SHIFTL(b"00001",2) has the value b"00100". 13.7.108c SHIFTR (I, SHIFT) <> Performs a right shift. <> Elemental function. <> I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE(I). <> Same as I. <> The value of the result is ISHFT(I,-SHIFT). <> SHIFTR(3,1) has the value 1. SHIFTR(b"10000",2) has the value b"00100". ..................................................................... [356:10+] Add a new intrinsic function, TRAILZ: 13.7.120a TRAILZ (I [,KIND]) <> Count the number of trailing zero bits. <> Elemental function. <> I shall be of type integer or bits. | KIND (optional) shall be a scalar integer initialization | expression. <> Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. <> If all of the bits of I are zero, the result value is BIT_SIZE(I). Otherwise, the result value is the position of the rightmost 1 bit in I, where the rightmost bit position is 0. The model for the interpretation of an integer value as a sequence of bits is in 13.3. <> TRAILZ(8) has the value 3. TRAILZ(b"101101000") has the value 3. ..................................................................... [391:25+] Add a new paragraph after the second paragraph in '15.1.1 Named constants and derived types in the module': The value of C_UINT shall be a valid value for a bits kind type parameter of the processor. The values of C_USHORT, C_ULONG, C_ULONG_LONG, C_USIGNED_CHAR, C_UINT8_T, C_UINT16_T, C_UINT32_T, C_UINT64_T, C_UINT_LEAST8_T, C_UINT_LEAST16_T, C_UINT_LEAST32_T, C_UINT_LEAST64_T, C_UINT_FAST8_T, C_UINT_FAST16_T, C_UINT_FAST32_T, C_UINT_FAST64_T, C_UINTMAX_T, C_UINTPTR_T, C_FLOAT_BITS, C_DOUBLE_BITS, C_LONG_DOUBLE_BITS, C_FLOAT_COMPLEX_BITS, C_DOUBLE_COMPLEX_BITS, C_LONG_DOUBLE_COMPLEX_BITS, and C_BOOL_BITS shall each be a valid value for a bits kind type parameter on the processor, -1 if the companion C processor defines the corresponding C type and there is no interoperating Fortran processor kind, or -2 if the C processor does not define the corresponding C type. ..................................................................... [396:14+] Within Table 15.2, 'Interoperability between Fortran and C types', add a new section after the row containing "C_INTPTR_T": ----------------------------------------------------------------- | C_UINT | unsigned int or int | C_USHORT | unsigned short or short | C_ULONG | unsigned long or long | C_ULONG_LONG | unsigned long long or | | long long | C_USIGNED_CHAR | unsigned char or | | signed char | C_UINT8_T | uint8_t or int8_t | C_UINT16_T | uint16_t or int16_t | C_UINT32_T | uint32_t or int32_t BITS | C_UINT64_T | uint64_t or int64_t | C_UINT_LEAST8_T | uint_least8_t or | | int_least8_t | C_UINT_LEAST16_T | uint_least16_t or | | int_least16_t | C_UINT_LEAST32_T | uint_least32_t or | | int_least32_t | C_UINT_LEAST64_T | uint_least64_t or | | int_least64_t | C_UINT_FAST8_T | uint_fast8_t or | | int_fast8_t | C_UINT_FAST16_T | uint_fast16_t or | | int_fast16_t | C_UINT_FAST32_T | uint_fast32_t or | | int_fast32_t | C_UINT_FAST64_T | uint_fast64_t or | | int_fast64_t | C_UINTMAX_T | uintmax_t or intmax_t | C_UINTPTR_T | uintptr_t or intptr_t | C_FLOAT_BITS | float | C_DOUBLE_BITS | double | C_LONG_DOUBLE_BITS | long double | C_FLOAT_COMPLEX_BITS | float _Complex | C_DOUBLE_COMPLEX_BITS | double _Complex | C_LONG_DOUBLE_COMPLEX_BITS | long double _Complex | C_BOOL_BITS | _Bool ..................................................................... [397:1-] After Note 15.9 at the end of '15.2.1 Inteoperability of intrinsic types' add a new Note: Note 15.9a If a variable of type bits is the actual argument corresponding to an unsigned integer parameter of a C function and is interoperable with that parameter, or the unsigned integer result of a C function is assigned to a variable of type bits that is interoperable with the function result, the I format can be used to output the correct form of the unsigned integer value. [end Note] ..................................................................... [416:8] In item 1 of the list in '16.4.3.1 Storage sequence' replace "default real, or default logical" with "default real, default logical, or default bits". ..................................................................... [416:11+] After item 2 of the list in '16.4.3.1 Storage sequence' add a new list item: (2a) A nonpointer scalar object of type bits with a kind type parameter that is an integer multiple, N, of the size of a numeric storage unit occupies N contiguous numeric storage units. The ordering of these consecutive numeric storage units is processor dependent. A nonpointer scalar object of type bits with a kind type parameter that is not an integer multiple of the size of a numeric storage unit occupies an unspecified storage unit that is different for each such kind value. ..................................................................... [416:18,20] In item (6) of the list in '16.4.3.1 Storage sequence', the edit above that adds a new item will require that the item numbers cited in (6) be changed from "(1)-(5)" and "(4)" to "(1)-(6)" and "(5)" respectively when the list is renumbered. ..................................................................... [416:28+] Add a new paragraph and Note at the end of '16.4.3.1 Storage sequence': Two objects for which the intrinsic function BITS_KIND returns the same value occupy the same amount of storage. Note 16.13a: A nonpointer nonallocatable scalar BITS object with a KIND value that is not an integer multiple of the size of a numeric storage unit in bits might be stored in a memory region larger than the minimum required to represent the value. For example, if BITS_KIND(x) has the value 13, the storage size for x might be 16 bite. Each element of a BITS array occupies the same size memory region as a scalar BITS object of the same kind. [end Note] .....................................................................