CVS difference for ai05s/ai05-0009-1.txt

--- ai05s/ai05-0009-1.txt	2008/05/29 04:36:46	1.6
+++ ai05s/ai05-0009-1.txt	2008/07/08 23:32:55	1.7
@@ -1,8 +1,14 @@
-!standard 9.10(1)                                      08-05-16    AI05-0009-1/05
+!standard 9.10(1)                                      08-07-08    AI05-0009-1/06
 !standard 13.1(15/1)
 !standard 13.2(9)
 !standard 13.3(13)
+!standard C.6(2)
+!standard C.6(4)
+!standard C.6(6)
+!standard C.6(9)
+!standard C.6(13)
 !class binding interpretation 06-03-21
+!status ARG Approved  8-0-0  08-06-21
 !status work item 06-03-21
 !status received 06-02-20
 !priority Medium
@@ -14,10 +20,10 @@
 
 The incorporation of confirming representation clauses has
 semantic implications for independent addressability.
-Two new pragmas (Independent and Independent_Components) to allow a user
-to specify that the components of a type should be
-independently addressable. Additionally, objects or types that have a
-convention specified by an interfacing pragma have
+Two new pragmas (Independent and Independent_Components) are introduced
+to allow a user to specify that the components of an object of a type
+should be independently addressable. Additionally, objects or types that
+have a convention specified by an interfacing pragma have
 been added to the kinds of representation items that impact
 independent addressability.
 
@@ -27,6 +33,9 @@
 A derived type can inherit a non-confirming representation clause,
 which is still considered non-confirming.
 
+Execution is erroneous if an address clause specifies a valid address
+that is not appropriate for the entity or its use.
+
 !question
 
 9.10(1) says that two nonoverlapping objects are independently addressable unless one or
@@ -40,14 +49,14 @@
 
 !wording
 
-Replace 9.10 (1) by:
+Replace 9.10(1) by:
 
 If two different objects, including nonoverlapping parts of the same
 object, are independently addressable, they can be manipulated
 concurrently by two different tasks without synchronization.
 Any two nonoverlapping objects are independently addressable if
-either object is atomic, if a pragma Independent applies to either
-object (see C.6), or if either is a component of a composite object
+either object is atomic (see C.6), if a pragma Independent applies to
+either object (see C.6), or if either is a component of a composite object
 to which pragma Independent_Components applies (see C.6). Otherwise,
 two nonoverlapping objects are independently addressable
 except when they are both parts of a composite object for which
@@ -57,11 +66,10 @@
 
 AARM Ramification: If the compiler cannot guarantee that an object
 (including a component) to which pragma Independent or pragma
-Independent_Components (see C.6) applies is independently
-addressable from any other nonoverlapping object, then the pragma
-must be rejected.
+Independent_Components applies is independently addressable from
+any other nonoverlapping object, then the pragma must be rejected.
 
-Similarly, an atomic object (including atomic components, see C.6)
+Similarly, an atomic object (including atomic components)
 is always independently addressable from any other nonoverlapping object.
 Any representation item which would prevent this from being true should
 be rejected, notwithstanding what this Standard says elsewhere.
@@ -90,7 +98,7 @@
 item for a derived type, the confirming representation item does not override
 the inherited one. Thus the derived type has both a specified confirming and
 an inherited non-confirming representation item -- this means that rules
-that don't apply to confirming representation items still apply to this type.
+that apply only to non-confirming representation items still apply to this type.
 
 
 Change 13.2(9) as follows:
@@ -105,15 +113,15 @@
 Change 13.3(13) as follows:
 
 If an Address is specified, it is the programmer's responsibility to ensure
-that the address is valid {and appropriate for the entity}; otherwise,
-program execution is erroneous. 
+that the address is valid {and appropriate for the entity and its use};
+otherwise, program execution is erroneous. 
 
-AARM Discussion: "Appropriate for the entity" covers cases such as
-misaligned addresses, read-only code addresses for data objects (and
-non-executable data addresses for code objects), and addresses which would
-force objects that are supposed to be independently addressable to not be.
-Such addresses may be "valid" as they designate locations that are
-accessible to the program, but the program execution is still erroneous
+AARM Discussion: "Appropriate for the entity and its use" covers cases
+such as misaligned addresses, read-only code addresses for variable data
+objects (and non-executable data addresses for code units), and addresses
+which would force objects that are supposed to be independently addressable
+to not be. Such addresses may be "valid" as they designate locations that
+are accessible to the program, but the program execution is still erroneous
 (meaning that implementations do not have to worry about these cases).
 
 
@@ -136,38 +144,21 @@
 The *array*_local_name in an 
 Atomic_Components or Volatile_Components pragma shall resolve to denote
 the declaration of an array type or an array object of an anonymous type.
-The local_name in an Independent_Components pragma shall resolve to denote
+{The local_name in an Independent_Components pragma shall resolve to denote
 the declaration of an array or record type or an array object of an anonymous
-type. [Editor's note: Do we want this last part? It's more consistent, but
-generally we haven't allowed Independent_xxx to apply to objects. If we don't
-want it, we should change from local_name to *type_*local_name.]
+type.}
 
 
 Add after C.6(13): [Legality Rules]
 
-It is illegal to apply a pragma Independent to a component that is not
-independently addressable from all other components of the enclosing type.
-It is illegal to apply pragma Independent_Components to a type unless all
-components are independently addressable from one another.
-
-If a pragma Independent_Components applies to a generic formal type, then
-a pragma Independent_Components shall also apply to the actual type.
-
-AARM Ramification: Independent_Components can only apply to a generic formal
-derived type by inheriting it from the ancestor. As a type-related
-representation pragma, it is not allowed directly on a generic untagged
-formal type (including formal array types).
-[Editor's note: It shouldn't be allowed on generic tagged private types
-(those act like partial views), either, but that is not covered by
-13.1(11/2). I'm not quite sure why (do we really want to deal with
-matching rules for representation pragmas on these types?).
-Surely we don't want pragma Pack to apply to generic formal types of
-any kind (or we would need to define matching rules or something).
-Perhaps descendants are OK (as it wouldn't apply to the parent part),
-but I don't think we want these on formals. Something may be wrong
-here... - I note that Ada 83 specifically says that representation
-clauses aren't allowed on generic formal types, that seems to have
-been lost somewhere.]
+It is illegal to apply either an Independent or Independent_Components pragma to
+a component, object, or type if the implementation cannot provide the independent
+addressability required by the pragma (see 9.10).
+
+It is illegal to specify a representation aspect for a component, object, or type
+to which pragma Independent or Independent_Components applies, in a way that
+prevents the implementation from providing the independent addressability required
+by the pragma.
 
 !discussion
 
@@ -200,7 +191,7 @@
 machine the pragma would be rejected because each component of
 A is not independently addressable.
 
-9.10 (1)
+9.10(1)
 
 Including non-confirming removes semantics associated with confirming
 representations. Convention was added to allow non-independent
@@ -247,10 +238,141 @@
 value of a type (see 13.9.1), and it mainly refers to the actual bit
 pattern of the value. Thus we add clarifying wording and an AARM note.
 
+!corrigendum 9.10(1)
+
+@drepl
+If two different objects, including nonoverlapping parts of the same
+object, are @i<independently addressable>, they can be manipulated
+concurrently by two different tasks without synchronization. Normally,
+any two nonoverlapping objects are independently addressable. However,
+if packing, record layout, or Component_Size is specified for a given
+composite object, then it is implementation defined whether or not two
+nonoverlapping parts of that composite object are independently
+addressable.
+@dby
+If two different objects, including nonoverlapping parts of the same
+object, are @i<independently addressable>, they can be manipulated
+concurrently by two different tasks without synchronization.
+Any two nonoverlapping objects are independently addressable if
+either object is atomic (see C.6), if a @fa<pragma> Independent applies to
+either object (see C.6), or if either is a component of a composite object
+to which @fa<pragma> Independent_Components applies (see C.6). Otherwise,
+two nonoverlapping objects are independently addressable
+except when they are both parts of a composite object for which
+a non-confirming representation item is used to specify
+packing, record layout, Component_Size, or convention, in which case
+it is unspecified whether the parts are independently addressable.
+
+!corrigendum 13.1(15/1)
+
+@drepl
+A derived type inherits each type-related aspect of representation of its
+parent type that was directly specified before the declaration of the derived
+type, or (in the case where the parent is derived) that was inherited by the
+parent type from the grandparent type. A derived subtype inherits each
+subtype-specific aspect of representation of its parent subtype that was
+directly specified before the declaration of the derived type, or (in the
+case where the parent is derived) that was inherited by the parent subtype
+from the grandparent subtype, but only if the parent subtype statically
+matches the first subtype of the parent type. An inherited aspect of
+representation is overridden by a subsequent representation item that
+specifies the same aspect of the type or subtype. 
+@drepl
+A derived type inherits each type-related aspect of representation of its
+parent type that was directly specified before the declaration of the derived
+type, or (in the case where the parent is derived) that was inherited by the
+parent type from the grandparent type. A derived subtype inherits each
+subtype-specific aspect of representation of its parent subtype that was
+directly specified before the declaration of the derived type, or (in the
+case where the parent is derived) that was inherited by the parent subtype
+from the grandparent subtype, but only if the parent subtype statically
+matches the first subtype of the parent type. An inherited aspect of
+representation is overridden by a subsequent representation item that
+specifies a different value for the same aspect of the type or subtype. 
+
+!corrigendum 13.2(9)
+
+@drepl
+@xbullet<For a packed array type, if the component subtype's Size is less than
+or equal to the word size, [and Component_Size is not specified for
+the type,] Component_Size should be less than or equal to the Size
+of the component subtype, rounded up to the nearest factor of the
+word size.>
+@dby
+@xbullet<For a packed array type, if the component subtype's Size is less than
+or equal to the word size, Component_Size should be less than or equal to the
+Size of the component subtype, rounded up to the nearest factor of the
+word size.>
+
+!corrigendum 13.3(13)
+
+@drepl
+If an Address is specified, it is the programmer's responsibility to ensure
+that the address is valid; otherwise, program execution is erroneous. 
+@dby
+If an Address is specified, it is the programmer's responsibility to ensure
+that the address is valid and appropriate for the entity and its use;
+otherwise, program execution is erroneous. 
+
+!corrigendum C.6(2)
+
+@drepl
+The form for pragmas Atomic, Volatile, Atomic_Components, and Volatile_Components is as follows:
+@dby
+The form for pragmas Atomic, Volatile, Independent, Atomic_Components, Volatile_Components, and
+Independent_Components is as follows:
+
+!corrigendum C.6(4)
+
+@dinsa
+@xindent<@b<pragma> Volatile(@fa<local_name>);>
+@dinst
+@xindent<@b<pragma> Independent(@i<component_>@fa<local_name>);>
 
+!corrigendum C.6(6)
 
-ACATS Tests
+@dinsa
+@xindent<@b<pragma> Volatile_Components(@i<array_>@fa<local_name>);>
+@dinst
+@xindent<@b<pragma> Independent_Components(@fa<local_name>);>
 
+!corrigendum C.6(9)
+
+@drepl
+The @fa<local_name> in an Atomic or Volatile pragma shall resolve
+to denote either an @fa<object_declaration>, a non-inherited @fa<component_declaration>,
+or a @fa<full_type_declaration>. The @i<array_>@fa<local_name> in an 
+Atomic_Components or Volatile_Components pragma shall resolve to denote
+the declaration of an array type or an array object of an anonymous type.
+@dby
+The @fa<local_name> in an Atomic or Volatile pragma shall resolve
+to denote either an @fa<object_declaration>, a non-inherited @fa<component_declaration>,
+or a @fa<full_type_declaration>. The @i<component_>@fa<local_name> in an Independent pragma
+shall resolve to denote a non-inherited @fa<component_declaration>.
+The @i<array_>@fa<local_name> in an 
+Atomic_Components or Volatile_Components pragma shall resolve to denote
+the declaration of an array type or an array object of an anonymous type.
+The @fa<local_name> in an Independent_Components pragma shall resolve to denote
+the declaration of an array or record type or an array object of an anonymous
+type.
+
+!corrigendum C.6(13)
+
+@dinsa
+If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components applies to a stand-alone
+constant object, then a pragma Import shall also apply to it. 
+@dinss
+It is illegal to apply either an Independent or Independent_Components pragma to
+a component, object, or type if the implementation cannot provide the independent
+addressability required by the pragma (see 9.10).
+
+It is illegal to specify a representation aspect for a component, object, or type
+to which pragma Independent or Independent_Components applies, in a way that
+prevents the implementation from providing the independent addressability required
+by the pragma.
+
+!ACATS Tests
+
 ACATS tests can be generated that would verify the rejection of the pragmas
 for all but bit-addressable architectures (TBD).  The verification of code
 generation is target dependent and probably can't be effectively tested.
@@ -2347,6 +2469,13 @@
 > Wouldn't that be fun?
 
 :-) :-) 
+
+****************************************************************
+
+Editor's note, Tuesday, July 8, 2008
+
+Although not previously noted, the lead-in paragraph (C.6(2)) to the syntax
+of the pragmas needs to be updated as well.
 
 ****************************************************************