2004-10-04 Robert Dewar <dewar@gnat.com>

	* exp_ch3.adb (Needs_Simple_Initialization): Modular packed arrays no
	longer need to be initialized to zero.
	(Get_Simple_Init_Val): Modular packed arrays no longer need to be
	initialized to zero.

	* checks.adb (Expr_Known_Valid): Packed arrays are now always
	considered valid, even if the representation is modular. That's correct
	now that we no longer initialize packed modular arrays to zero.

	* exp_dbug.ads: Clarify documentation on handling of PAD and JM
	suffixes. These are now documented as the only cases in which the
	debugger ignores outer records.
	Previously, the spec allowed arbitrary suffixes for this purpose.
	Change name of LJM to JM for packed array pad records
	Create separate section on packed array handling, and add a whole new
	set of comments to this section describing the situation with packed
	modular types and justification requirements depending on endianness.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@88500 138bc75d-0d04-0410-961f-82ee72b054a4

4 files changed, 106 insertions, 38 deletions

diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
index e7bd215c0b9..043d3e120ad 100644
--- a/gcc/ada/ChangeLog
+++ b/gcc/ada/ChangeLog
@@ -1,5 +1,25 @@
 2004-10-04  Robert Dewar  <dewar@gnat.com>
 
+	* exp_ch3.adb (Needs_Simple_Initialization): Modular packed arrays no
+	longer need to be initialized to zero.
+	(Get_Simple_Init_Val): Modular packed arrays no longer need to be
+	initialized to zero.
+
+	* checks.adb (Expr_Known_Valid): Packed arrays are now always
+	considered valid, even if the representation is modular. That's correct
+	now that we no longer initialize packed modular arrays to zero.
+
+	* exp_dbug.ads: Clarify documentation on handling of PAD and JM
+	suffixes. These are now documented as the only cases in which the
+	debugger ignores outer records.
+	Previously, the spec allowed arbitrary suffixes for this purpose.
+	Change name of LJM to JM for packed array pad records
+	Create separate section on packed array handling, and add a whole new
+	set of comments to this section describing the situation with packed
+	modular types and justification requirements depending on endianness.
+
+2004-10-04  Robert Dewar  <dewar@gnat.com>
+
 	* a-except.adb: Add a comment for last change
 
 	* einfo.ads: Minor spelling correction in comment
diff --git a/gcc/ada/checks.adb b/gcc/ada/checks.adb
index 6f741011377..357d9f290ec 100644
--- a/gcc/ada/checks.adb
+++ b/gcc/ada/checks.adb
@@ -3724,12 +3724,16 @@ package body Checks is
       Typ : constant Entity_Id := Etype (Expr);
 
    begin
-      --  Non-scalar types are always consdered valid, since they never
+      --  Non-scalar types are always considered valid, since they never
       --  give rise to the issues of erroneous or bounded error behavior
       --  that are the concern. In formal reference manual terms the
-      --  notion of validity only applies to scalar types.
+      --  notion of validity only applies to scalar types. Note that
+      --  even when packed arrays are represented using modular types,
+      --  they are still arrays semantically, so they are also always
+      --  valid (in particular, the unused bits can be random rubbish
+      --  without affecting the validity of the array value).
 
-      if not Is_Scalar_Type (Typ) then
+      if not Is_Scalar_Type (Typ) or else Is_Packed_Array_Type (Typ) then
          return True;
 
       --  If no validity checking, then everything is considered valid
diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
index 631900a7c93..52394d376c2 100644
--- a/gcc/ada/exp_ch3.adb
+++ b/gcc/ada/exp_ch3.adb
@@ -5046,29 +5046,6 @@ package body Exp_Ch3 is
          return
            Make_Null (Loc);
 
-      --  We initialize modular packed bit arrays to zero, to make sure that
-      --  unused bits are zero, as required (see spec of Exp_Pakd). Also note
-      --  that this improves gigi code, since the value tracing knows that
-      --  all bits of the variable start out at zero. The value of zero has
-      --  to be unchecked converted to the proper array type.
-
-      elsif Is_Bit_Packed_Array (T) then
-         declare
-            PAT : constant Entity_Id := Packed_Array_Type (T);
-            Nod : Node_Id;
-
-         begin
-            pragma Assert (Is_Modular_Integer_Type (PAT));
-
-            Nod :=
-              Make_Unchecked_Type_Conversion (Loc,
-                Subtype_Mark => New_Occurrence_Of (T, Loc),
-                Expression   => Make_Integer_Literal (Loc, 0));
-
-            Set_Etype (Expression (Nod), PAT);
-            return Nod;
-         end;
-
       --  No other possibilities should arise, since we should only be
       --  calling Get_Simple_Init_Val if Needs_Simple_Initialization
       --  returned True, indicating one of the above cases held.
@@ -5586,8 +5563,6 @@ package body Exp_Ch3 is
 
       elsif Is_Access_Type (T)
         or else (Init_Or_Norm_Scalars and then (Is_Scalar_Type (T)))
-        or else (Is_Bit_Packed_Array (T)
-                   and then Is_Modular_Integer_Type (Packed_Array_Type (T)))
       then
          return True;
 
diff --git a/gcc/ada/exp_dbug.ads b/gcc/ada/exp_dbug.ads
index 0abca3055ca..70bcf95af3e 100644
--- a/gcc/ada/exp_dbug.ads
+++ b/gcc/ada/exp_dbug.ads
@@ -494,18 +494,26 @@ package Exp_Dbug is
 
       --  In this case the compile generates a structure type y___PAD, which
       --  has a single field whose name is F. This single field is 64 bits
-      --  long and contains the actual value.
+      --  long and contains the actual value. This kind of padding is used
+      --  when the logical value to be stored is shorter than the object in
+      --  which it is allocated. For example if a size clause is used to set
+      --  a size of 256 for a signed integer value, then a typical choice is
+      --  to wrap a 64-bit integer in a 256 bit PAD structure.
 
       --  A similar encapsulation is done for some packed array types,
-      --  in which case the structure type is y___LJM and the field name
-      --  is OBJECT.
+      --  in which case the structure type is y___JM and the field name
+      --  is OBJECT. This is used in the case of a packed array stored
+      --  in modular representation (see section on representation of
+      --  packed array objects). In this case the JM wrapping is used to
+      --  achieve correct positioning of the packed array value (left or
+      --  right justified in its field depending on endianness.
 
       --  When the debugger sees an object of a type whose name has a
-      --  suffix not otherwise mentioned in this specification, the type
-      --  is a record containing a single field, and the name of that field
-      --  is all upper-case letters, it should look inside to get the value
-      --  of the field, and neither the outer structure name, nor the
-      --  field name should appear when the value is printed.
+      --  suffix of ___PAD or ___JM, the type will be a record containing
+      --  a single field, and the name of that field will be all upper case.
+      --  In this case, it should look inside to get the value of the inner
+      --  field, and neither the outer structure name, nor the field name
+      --  should appear when the value is printed.
 
       -----------------------
       -- Fixed-Point Types --
@@ -1074,6 +1082,10 @@ package Exp_Dbug is
    --  in this manner, it can use the original type to determine the bounds,
    --  and the component size to determine the packing details.
 
+   -------------------------------------------
+   -- Packed Array Representation in Memory --
+   -------------------------------------------
+
    --  Packed arrays are represented in tightly packed form, with no extra
    --  bits between components. This is true even when the component size
    --  is not a factor of the storage unit size, so that as a result it is
@@ -1100,7 +1112,7 @@ package Exp_Dbug is
 
    --        BV'Address + 2   BV'Address + 1    BV'Address + 0
    --     +-----------------+-----------------+-----------------+
-   --     | 0 0 0 0 0 0 1 1 | 0 1 0 1 1 0 0 0 | 1 1 0 1 0 0 0 1 |
+   --     | ? ? ? ? ? ? 1 1 | 0 1 0 1 1 0 0 0 | 1 1 0 1 0 0 0 1 |
    --     +-----------------+-----------------+-----------------+
    --       <---------> <-----> <---> <---> <-----> <---> <--->
    --       unused bits  BV(5)  BV(4) BV(3)  BV(2)  BV(1) BV(0)
@@ -1109,11 +1121,68 @@ package Exp_Dbug is
    --
    --        BV'Address + 0  BV'Address + 1    BV'Address + 2
    --     +-----------------+-----------------+-----------------+
-   --     | 0 0 1 0 1 0 0 1 | 1 1 0 0 1 0 1 1 | 1 0 0 0 0 0 0 0 |
+   --     | 0 0 1 0 1 0 0 1 | 1 1 0 0 1 0 1 1 | 1 0 ? ? ? ? ? ? |
    --     +-----------------+-----------------+-----------------+
    --       <---> <---> <-----> <---> <---> <-----> <--------->
    --       BV(0) BV(1)  BV(2)  BV(3) BV(4)  BV(5)  unused bits
 
+   --  Note that if a modular type is used to represent the array, the
+   --  allocation in memory is not the same as a normal modular type.
+   --  The difference occurs when the allocated object is larger than
+   --  the size of the array. For a normal modular type, we extend the
+   --  value on the left with zeroes.
+
+   --  For example, in the normal modular case, if we have a 6-bit
+   --  modular type, declared as mod 2**6, and we allocate an 8-bit
+   --  object for this type, then we extend the value with two bits
+   --  on the most significant end, and in either the little-endian
+   --  or big-endian case, the value 63 is represented as 00111111
+   --  in binary in memory.
+
+   --  For a modular type used to represent a packed array, the rule is
+   --  different. In this case, if we have to extend the value, then we
+   --  do it with undefined bits (which are not initialized and whose value
+   --  is irrelevant to any generated code). Furthermore these bits are on
+   --  the right (least significant bits) in the big-endian case, and on the
+   --  left (most significant bits) in the little-endian case.
+
+   --  For example, if we have a packed boolean array of 6 bits, all set
+   --  to True, stored in an 8-bit object, then the value in memory in
+   --  binary is ??111111 in the little-endian case, and 111111?? in the
+   --  big-endian case.
+
+   --  This is done so that the representation of packed arrays does not
+   --  depend on whether we use a modular representation or array of bytes
+   --  as previously described. This ensures that we can pass such values
+   --  by reference in the case where a subprogram has to be able to handle
+   --  values stored in either form.
+
+   --  Note that when we extract the value of such a modular packed array,
+   --  we expect to retrieve only the relevant bits, so in this same example,
+   --  when we extract the value, we get 111111 in both cases, and the code
+   --  generated by the front end assumes this, although it does not assume
+   --  that any high order bits are defined.
+
+   --  There are opportunities for optimization based on the knowledge that
+   --  the unused bits are irrelevant for these type of packed arrays. For
+   --  example if we have two such 6-bit-in-8-bit values and we do an
+   --  assignment:
+
+   --     a := b;
+
+   --  Then logically, we extract the 6 bits and store only 6 bits in the
+   --  result, but the back end is free to simply assign the entire 8-bits
+   --  in this case, since we don't actually care about the undefined bits.
+   --  However, in the equality case, it is important to ensure that the
+   --  undefined bits do not participate in an equality test.
+
+   --  If a modular packed array value is assigned to a register, then
+   --  logically it could always be held right justified, to avoid any
+   --  need to shift, e.g. when doing comparisons. But probably this is
+   --  a bad choice, as it would mean that an assignment such as a := b
+   --  above would require shifts when one value is in a register and the
+   --  other value is in memory.
+
    ------------------------------------------------------
    -- Subprograms for Handling Packed Array Type Names --
    ------------------------------------------------------