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

--- ai05s/ai05-0009-1.txt	2007/05/24 01:17:40	1.3
+++ ai05s/ai05-0009-1.txt	2008/02/28 06:39:08	1.4
@@ -1,4 +1,7 @@
-!standard 9.10(1)                                      07-05-20    AI05-0009-1/03
+!standard 9.10(1)                                      08-02-26    AI05-0009-1/04
+!standard 13.1(15/1)
+!standard 13.2(9)
+!standard 13.3(13)
 !class binding interpretation 06-03-21
 !status work item 06-03-21
 !status received 06-02-20
@@ -12,12 +15,18 @@
 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 an object or type should be
+to specify that the components of a type should be
 independently addressable. Additionally, objects or types that have a
-convention (other than Ada) specified by an interfacing pragma have
+convention specified by an interfacing pragma have
 been added to the kinds of representation items that impact
 independent addressability.
 
+Atomic objects are always independently addressable from any other
+nonoverlapping object (no matter what representation clauses apply).
+
+A derived type can inherit a non-confirming representation clause,
+which is still considered non-confirming.
+
 !question
 
 9.10(1) says that two nonoverlapping objects are independently addressable unless one or
@@ -26,69 +35,152 @@
 they can affect independent addressibility. Is this intended? (No.)
 
 !recommendation
-
-Modify 9.10 to identify only non-confirming representations as those
-that can cause dependent addressability.  Modify to include
-convention as an item that can cause an object to be dependent
-(exclude convention Ada) for a representation. Change dependent
-addressability from implementation defined to unspecified.
-
-Add pragmas Independent and Independent_Components to C.6.  Independent
-applies to components of record types; Independent_Components
-applies to components of arrays or anonymous array objects.
 
-Also update the AARM notes in 13.1 (8.v, 8.w; 8.gg, 8.hh) to add the
-new pragmas independent and independent components.
+(See summary.)
 
 !wording
 
-Modify 9.10 (1) to read:
+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.
 Normally, any two nonoverlapping objects are independently addressable.
-However, if a non-confirming representation item is used to specify
-packing, record layout, Component_Size, or a convention other than Ada,
-then the independent addressability of the object (and subcomponents)
-is unspecified.
-
-Add or modify C.6 as follows:
-
-Add to Syntax
+However, if a non-confirming representation item is used to specify packing,
+record layout, Component_Size, or the convention for a given composite object
+that is not atomic, then it is unspecified whether or not two nonoverlapping
+parts of that composite object are independently addressable.
+Notwithstanding the previous, an atomic component is always independently
+addressable from any other nonoverlapping part of any enclosing object.
+
+AARM Ramification: A component to which pragma Independent or pragma
+Independent_Components (see C.6) applies is always independently
+addressable from any other nonoverlapping component of the enclosing
+object. If that is not true, the pragma must be rejected.
+
+AARM Ramification: An atomic object (including atomic components, see C.6)
+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.
+
+[Editor's notes: There are two problems with this wording that I can't seem
+to figure out.
+(1) I can't figure out how to work atomic components of non-atomic objects
+into this wording. The best I can do is given above, and it is barf-inducing.
+(2) I not convinced this actually works in the case of a non-confirming
+representation item and a pragma Independent_Components. Consider:
+    type OK is array (1..4) of Character;
+    for OK'Component_Size use 16;
+    pragma Independent_Components (OK);
+type OK should have independent addressable components if these clauses
+are accepted (and I'd expect that they would be on most compilers). But
+the above wording says that whether this is true is unspecified.
+One can argue that the wording of C.6 supercedes this (and that is what
+I wrote in the AARM note), but I don't like the conflicting wording - it
+is confusing at best and misleading at worst. Maybe add some "Redundant"
+text to explain this??]
 
-pragma Independent (
-      [Entity => ] local_name
-      {,[Component =>] *component*_local_name});
 
-Pragma Independent_Components(*array*_local_name);
-
-An *independent component* is a component to which a pragma Independent
-or pragma Independent_Components applies.
-
-Modify Name Resolution
-
-The local_name in an Atomic or Volatile pragma shall resolve to denote
-either an object_declaration, a non-inherited component_declaration,
-or a full_type_declaration. The local_name in an Independent pragma shall
-resolve to denote a full_type_declaration of a record_type_definition; the
-*component*_local_name shall resolve to denote a non-inherited component
-of the full_type_declaration. The *array*_local_name in an 
-Atomic_Components, Volatile_Components or Independent_Components
-pragma shall ...
-
-Add to Legality Rules
-
-It is illegal to apply a pragma Independent or Independent_Components
-to an independent component when the component is not independently
-addressable.
+Update the AARM notes in 13.1 (8.v, 8.w; 8.hh) to add the
+new pragmas independent and independent components.
 
-If a pragma Independent or Independent_Components applies to a generic
-formal type, then the actual type must have independent components.
 
-Add to Static Semantics
+Change 13.1(15/1) as follows:
 
-An independent component is independently addressable.
+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. 
+
+AARM Ramification: If an inherited aspect is confirmed by a later representation
+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 exclude confirming representation items still apply to this type.
+
+
+Change 13.2(9) as follows:
+
+* 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.
+
+
+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. 
+
+AARM Discussion: "Appropriate for the entity" covers cases such as
+misaligned addresses, code addresses for data objects (and vice versa),
+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).
+
+
+Add after C.6(4): [Syntax]
+
+pragma Independent (*component*_local_name);
+
+
+Add after C.6(6):
+
+pragma Independent_Components(local_name);
+
+
+Change C.6(9) as follows: [Name Resolution]
+
+The local_name in an Atomic or Volatile pragma shall resolve
+to denote either an object_declaration, a non-inherited component_declaration,
+or a full_type_declaration. {The *component*_local_name in an Independent pragma
+shall resolve to denote a non-inherited component_declaration.}
+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 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.]
+
+
+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.]
 
 !discussion
 
@@ -98,8 +190,8 @@
    A : array (1..4) of character;
    for A'Component_Size use 8;
 
-The components of A are no longer independent, which allows different
-encodings of the following statements:
+The components of A are no longer independent by the original wording,
+which allows different encodings of the following statements:
 
 A (1) := <char>;
 A (4) := <char>;
@@ -124,22 +216,49 @@
 9.10 (1)
 
 Including non-confirming removes semantics associated with confirming
-representations.  Convention was added to allow dependent addressability
-for conventions other than Ada.
+representations. Convention was added to allow non-independent
+addressability for conventions other than Ada. Atomic objects always
+have independent addressability compared to any other object (including
+components). This is necessary so that the intent that tasks can
+access such objects safely without synchronization is accomplished.
 
 C.6
 
-Introduces the new pragmas, defining independent to be applicable to
-all record types, except arrays which will require Independent_Components.
+Introduces the new pragmas, defining Independent to be applicable to
+individual record components, and Independent_Components which
+applies to array and record types.
 Pragma independent and Independent_Components are similar to Volatile and
-Atomic in that only a single entity name is accepted with the pragma
-(conflicts with 13.1 (5/1, 6/1)).
+Atomic in that only a single entity name is accepted with the pragma.
 
-The minutes from Albuquerque identify that pragma independent_components
+The minutes from Albuquerque identify that pragma Independent_Components
 should be considered for all composite types; however, there is no way
 to remove independence for the components of tasks or protected types,
-so the pragma was not allowed for tasks and protected types.
+so the pragma is not needed for those types. Moreover, as a representation
+pragma, it is not allowed on partial views (by 13.1(9)), so we only
+need allow array and record types.
 
+
+
+A separate problem was identified during the preparation of this AI.
+A confirming representation item specifies the value that the compiler
+would have chosen anyway. However, a derived type can inherit a
+non-confirming representation value; if this value is then specified,
+we want to be remain non-confirming.
+
+We also noted that 13.2(9) seems to allow different behavior if a
+confirming representation clause is given, which breaks the model that
+confirming representation clauses never change anything.
+
+It was also noted that an address specified in an address clause could
+be used to break independent addressibility in places where it was
+required. 13.3(13) could cover this by using a expansive reading of
+"valid" (where an address isn't valid if it causes some violation of
+semantics even if it is legitimate address for the target), but
+hardly anyone [Editor's note: except Tucker! ;-)] reads this paragraph
+that way. Thus we add clarifying wording and an AARM note.
+
+
+
 ACATS Tests
 
 ACATS tests can be generated that would verify the rejection of the pragmas
@@ -2185,6 +2304,20 @@
 appropriately, pretty much this is something worth worrying about only if
 there is a bug report from a customer (for instance, if a code generator
 gets too aggressive combining instructions).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 28, 2007 12:28 AM
+
+I've completed an update of AI05-0009-1 [this is version /04 of the
+AI - ED] based on the ARG discussion from the Paris meeting (the
+last time this AI was discussed). I'm still a bit uncertain if I
+have the wording right and all of the cases covered. You can find
+my concerns by reading the "Editor's notes" in the AI. Comments and
+suggestions are welcome.
+
+                  Randy.
 
 ****************************************************************