exp_dbug.ads, [...] (Get_External_Name): Add missing initialization of Homonym_Len.

2006-10-31  Robert Dewar  <dewar@adacore.com>

	* exp_dbug.ads, exp_dbug.adb (Get_External_Name): Add missing
	initialization of Homonym_Len.
	(Fully_Qualify_Name): Remove kludge to eliminate anonymous block
	names from fully qualified name. Fixes problem of duplicate
	external names differing only in the presence of such a block name.

From-SVN: r118263

gcc/ada/exp_dbug.adb

@@ -36,7 +36,6 @@ with Output;   use Output;
 with Sem_Eval; use Sem_Eval;
 with Sem_Util; use Sem_Util;
 with Sinfo;    use Sinfo;
-with Snames;   use Snames;
 with Stand;    use Stand;
 with Stringt;  use Stringt;
 with Table;
@@ -546,7 +545,6 @@ package body Exp_Dbug is
       --  Vax floating-point case
 
       elsif Vax_Float (E) then
-
          if Digits_Value (Base_Type (E)) = 6 then
             Get_External_Name_With_Suffix (E, "XFF");
 
@@ -679,13 +677,13 @@ package body Exp_Dbug is
          else
             Get_Name_String_And_Append (Chars (Entity));
          end if;
-
       end Get_Qualified_Name_And_Append;
 
    --  Start of processing for Get_External_Name
 
    begin
-      Name_Len := 0;
+      Name_Len    := 0;
+      Homonym_Len := 0;
 
       --  If this is a child unit, we want the child
 
@@ -887,9 +885,10 @@ package body Exp_Dbug is
    ------------------------------------
 
    procedure Get_Secondary_DT_External_Name
-     (Typ             : Entity_Id;
-      Ancestor_Typ    : Entity_Id;
-      Suffix_Index    : Int) is
+     (Typ          : Entity_Id;
+      Ancestor_Typ : Entity_Id;
+      Suffix_Index : Int)
+   is
    begin
       Get_External_Name (Typ, Has_Suffix => False);
 
@@ -1116,26 +1115,13 @@ package body Exp_Dbug is
                Get_Name_String (Chars (E));
             end if;
 
-            --  A special check here, we never add internal block or loop
-            --  names, since they intefere with debugging. We identify these
-            --  by the fact that they start with an upper case B or L.
-            --  But do add these if what we are qualifying is a __clean
-            --  procedure since those need to be made unique.
+            --  Here we do one step of the qualification
 
-            if (Name_Buffer (1) = 'B' or else Name_Buffer (1) = 'L')
-                and then (not Debug_Flag_VV)
-                and then Full_Qualify_Len > 2
-                and then Chars (Ent) /= Name_uClean
-            then
-               Full_Qualify_Len := Full_Qualify_Len - 2;
-
-            else
-               Full_Qualify_Name
-                 (Full_Qualify_Len + 1 .. Full_Qualify_Len + Name_Len) :=
-                   Name_Buffer (1 .. Name_Len);
-               Full_Qualify_Len := Full_Qualify_Len + Name_Len;
-               Append_Homonym_Number (E);
-            end if;
+            Full_Qualify_Name
+              (Full_Qualify_Len + 1 .. Full_Qualify_Len + Name_Len) :=
+                 Name_Buffer (1 .. Name_Len);
+            Full_Qualify_Len := Full_Qualify_Len + Name_Len;
+            Append_Homonym_Number (E);
          end if;
 
          if Is_BNPE (E) then

gcc/ada/exp_dbug.ads

@@ -6,7 +6,7 @@
 --                                                                          --
 --                                 S p e c                                  --
 --                                                                          --
---          Copyright (C) 1996-2005, Free Software Foundation, Inc.         --
+--          Copyright (C) 1996-2006, Free Software Foundation, Inc.         --
 --                                                                          --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -50,18 +50,18 @@ package Exp_Dbug is
    --  as described in Namet). Upper case letters are used only for entities
    --  generated by the compiler.
 
-   --  There are two cases, global entities, and local entities. In more
-   --  formal terms, local entities are those which have a dynamic enclosing
-   --  scope, and global entities are at the library level, except that we
-   --  always consider procedures to be global entities, even if they are
-   --  nested (that's because at the debugger level a procedure name refers
-   --  to the code, and the code is indeed a global entity, including the
-   --  case of nested procedures.) In addition, we also consider all types
-   --  to be global entities, even if they are defined within a procedure.
+   --  There are two cases, global entities, and local entities. In more formal
+   --  terms, local entities are those which have a dynamic enclosing scope,
+   --  and global entities are at the library level, except that we always
+   --  consider procedures to be global entities, even if they are nested
+   --  (that's because at the debugger level a procedure name refers to the
+   --  code, and the code is indeed a global entity, including the case of
+   --  nested procedures.) In addition, we also consider all types to be global
+   --  entities, even if they are defined within a procedure.
 
-   --  The reason for treating all type names as global entities is that
-   --  a number of our type encodings work by having related type names,
-   --  and we need the full qualification to keep this unique.
+   --  The reason for treating all type names as global entities is that a
+   --  number of our type encodings work by having related type names, and we
+   --  need the full qualification to keep this unique.
 
    --  For global entities, the encoded name includes all components of the
    --  fully expanded name (but omitting Standard at the start). For example,
@@ -69,16 +69,16 @@ package Exp_Dbug is
    --  there is an entity in this embdded package whose name is S, the encoded
    --  name will include the components p.q.r.s.
 
-   --  For local entities, the encoded name only includes the components
-   --  up to the enclosing dynamic scope (other than a block). At run time,
-   --  such a dynamic scope is a subprogram, and the debugging formats know
-   --  about local variables of procedures, so it is not necessary to have
-   --  full qualification for such entities. In particular this means that
-   --  direct local variables of a procedure are not qualified.
+   --  For local entities, the encoded name only includes the components up to
+   --  the enclosing dynamic scope (other than a block). At run time, such a
+   --  dynamic scope is a subprogram, and the debugging formats know about
+   --  local variables of procedures, so it is not necessary to have full
+   --  qualification for such entities. In particular this means that direct
+   --  local variables of a procedure are not qualified.
 
    --  As an example of the local name convention, consider a procedure V.W
-   --  with a local variable X, and a nested block Y containing an entity
-   --  Z. The fully qualified names of the entities X and Z are:
+   --  with a local variable X, and a nested block Y containing an entity Z.
+   --  The fully qualified names of the entities X and Z are:
 
    --    V.W.X
    --    V.W.Y.Z
@@ -95,11 +95,11 @@ package Exp_Dbug is
       -- Handling of Overloading --
       -----------------------------
 
-      --  The above scheme is incomplete with respect to overloaded
-      --  subprograms, since overloading can legitimately result in a
-      --  case of two entities with exactly the same fully qualified names.
-      --  To distinguish between entries in a set of overloaded subprograms,
-      --  the encoded names are serialized by adding the suffix:
+      --  The above scheme is incomplete for overloaded subprograms, since
+      --  overloading can legitimately result in case of two entities with
+      --  exactly the same fully qualified names. To distinguish between
+      --  entries in a set of overloaded subprograms, the encoded names are
+      --  serialized by adding the suffix:
 
       --    __nn  (two underscores)
 
@@ -107,9 +107,9 @@ package Exp_Dbug is
       --  3 for the third, etc.). A suffix of __1 is always omitted (i.e. no
       --  suffix implies the first instance).
 
-      --  These names are prefixed by the normal full qualification. So
-      --  for example, the third instance of the subprogram qrs in package
-      --  yz would have the name:
+      --  These names are prefixed by the normal full qualification. So for
+      --  example, the third instance of the subprogram qrs in package yz
+      --  would have the name:
 
       --    yz__qrs__3
 
@@ -126,11 +126,11 @@ package Exp_Dbug is
 
       --    __nn_nn_nn ...
 
-      --  where the nn values are the homonym numbers as needed for any of
-      --  the qualifying entities, separated by a single underscore. If all
-      --  the nn values are 1, the suffix is omitted, Otherwise the suffix
-      --  is present (including any values of 1). The following example
-      --  shows how this suffixing works.
+      --  where the nn values are the homonym numbers as needed for any of the
+      --  qualifying entities, separated by a single underscore. If all the nn
+      --  values are 1, the suffix is omitted, Otherwise the suffix is present
+      --  (including any values of 1). The following example shows how this
+      --  suffixing works.
 
       --    package body Yz is
       --      procedure Qrs is               -- Name is yz__qrs
@@ -152,10 +152,10 @@ package Exp_Dbug is
       -- Operator Names --
       --------------------
 
-      --   The above rules applied to operator names would result in names
-      --   with quotation marks, which are not typically allowed by assemblers
-      --   and linkers, and even if allowed would be odd and hard to deal with.
-      --   To avoid this problem, operator names are encoded as follows:
+      --   The above rules applied to operator names would result in names with
+      --   quotation marks, which are not typically allowed by assemblers and
+      --   linkers, and even if allowed would be odd and hard to deal with. To
+      --   avoid this problem, operator names are encoded as follows:
 
       --    Oabs       abs
       --    Oand       and
@@ -179,8 +179,8 @@ package Exp_Dbug is
 
       --  These names are prefixed by the normal full qualification, and
       --  suffixed by the overloading identification. So for example, the
-      --  second operator "=" defined in package Extra.Messages would
-      --  have the name:
+      --  second operator "=" defined in package Extra.Messages would have
+      --  the name:
 
       --    extra__messages__Oeq__2
 
@@ -189,9 +189,9 @@ package Exp_Dbug is
       ----------------------------------
 
       --  It might be thought that the above scheme is complete, but in Ada 95,
-      --  full qualification is insufficient to uniquely identify an entity
-      --  in the program, even if it is not an overloaded subprogram. There
-      --  are two possible confusions:
+      --  full qualification is insufficient to uniquely identify an entity in
+      --  the program, even if it is not an overloaded subprogram. There are
+      --  two possible confusions:
 
       --     a.b
 
@@ -203,8 +203,8 @@ package Exp_Dbug is
       --       interpretation 1: entity c in child package a.b
       --       interpretation 2: entity c in nested package b in body of a
 
-      --  It is perfectly legal in both cases for both interpretations to
-      --  be valid within a single program. This is a bit of a surprise since
+      --  It is perfectly legal in both cases for both interpretations to be
+      --  valid within a single program. This is a bit of a surprise since
       --  certainly in Ada 83, full qualification was sufficient, but not in
       --  Ada 95. The result is that the above scheme can result in duplicate
       --  names. This would not be so bad if the effect were just restricted
@@ -213,7 +213,7 @@ package Exp_Dbug is
       --  a real problem of name clashes.
 
       --  To deal with this situation, we provide two additional encoding
-      --  rules for names
+      --  rules for names:
 
       --    First: all library subprogram names are preceded by the string
       --    _ada_ (which causes no duplications, since normal Ada names can
@@ -835,30 +835,30 @@ package Exp_Dbug is
       -- Base Record Types --
       -----------------------
 
-      --  Under certain circumstances, debuggers need two descriptions
-      --  of a record type, one that gives the actual details of the
-      --  base type's structure (as described elsewhere in these
-      --  comments) and one that may be used to obtain information
-      --  about the particular subtype and the size of the objects
-      --  being typed. In such cases the compiler will substitute a
-      --  type whose name is typically compiler-generated and
+      --  Under certain circumstances, debuggers need two descriptions of a
+      --  record type, one that gives the actual details of the base type's
+      --  structure (as described elsewhere in these comments) and one that may
+      --  be used to obtain information about the particular subtype and the
+      --  size of the objects being typed. In such cases the compiler will
+      --  substitute type whose name is typically compiler-generated and
       --  irrelevant except as a key for obtaining the actual type.
-      --  Specifically, if this name is x, then we produce a record
-      --  type named x___XVS consisting of one field. The name of
-      --  this field is that of the actual type being encoded, which
-      --  we'll call y (the type of this single field is arbitrary).
-      --  Both x and y may have corresponding ___XVE types.
-
-      --  The size of the objects typed as x should be obtained from
-      --  the structure of x (and x___XVE, if applicable) as for
-      --  ordinary types unless there is a variable named x___XVZ, which,
-      --  if present, will hold the the size (in bits) of x.
-
-      --  The type x will either be a subtype of y (see also Subtypes
-      --  of Variant Records, below) or will contain no fields at
-      --  all. The layout, types, and positions of these fields will
-      --  be accurate, if present. (Currently, however, the GDB
-      --  debugger makes no use of x except to determine its size).
+
+      --  Specifically, if this name is x, then we produce a record type named
+      --  x___XVS consisting of one field. The name of this field is that of
+      --  the actual type being encoded, which we'll call y (the type of this
+      --  single field is arbitrary). Both x and y may have corresponding
+      --  ___XVE types.
+
+      --  The size of the objects typed as x should be obtained from the
+      --  structure of x (and x___XVE, if applicable) as for ordinary types
+      --  unless there is a variable named x___XVZ, which, if present, will
+      --  hold the the size (in bits) of x.
+
+      --  The type x will either be a subtype of y (see also Subtypes of
+      --  Variant Records, below) or will contain no fields at all. The layout,
+      --  types, and positions of these fields will be accurate, if present.
+      --  (Currently, however, the GDB debugger makes no use of x except to
+      --  determine its size).
 
       --  Among other uses, XVS types are sometimes used to encode
       --  unconstrained types. For example, given
@@ -889,12 +889,11 @@ package Exp_Dbug is
       --
       --     at1___C_PAD___XVZ: constant Integer := 32 + M * 8 + padding term;
       --
-      --  Not all unconstrained types are so encoded; the XVS
-      --  convention may be unnecessary for unconstrained types of
-      --  fixed size. However, this encoding is always necessary when
-      --  a subcomponent type (array element's type or record field's
-      --  type) is an unconstrained record type some of whose
-      --  components depend on discriminant values.
+      --  Not all unconstrained types are so encoded; the XVS convention may be
+      --  unnecessary for unconstrained types of fixed size. However, this
+      --  encoding is always necessary when a subcomponent type (array
+      --  element's type or record field's type) is an unconstrained record
+      --  type some of whose components depend on discriminant values.
 
       -----------------
       -- Array Types --
@@ -906,39 +905,38 @@ package Exp_Dbug is
       --  are the names of the types for the bounds. The types of these
       --  fields is an integer type which is meaningless.
 
-      --  To conserve space, we do not produce this type unless one of
-      --  the index types is either an enumeration type, has a variable
-      --  upper bound, has a lower bound different from the constant 1,
-      --  is a biased type, or is wider than "sizetype".
+      --  To conserve space, we do not produce this type unless one of the
+      --  index types is either an enumeration type, has a variable upper
+      --  bound, has a lower bound different from the constant 1, is a biased
+      --  type, or is wider than "sizetype".
 
       --  Given the full encoding of these types (see above description for
       --  the encoding of discrete types), this means that all necessary
-      --  information for addressing arrays is available. In some
-      --  debugging formats, some or all of the bounds information may
-      --  be available redundantly, particularly in the fixed-point case,
-      --  but this information can in any case be ignored by the debugger.
+      --  information for addressing arrays is available. In some debugging
+      --  formats, some or all of the bounds information may be available
+      --  redundantly, particularly in the fixed-point case, but this
+      --  information can in any case be ignored by the debugger.
 
       ----------------------------
       -- Note on Implicit Types --
       ----------------------------
 
-      --  The compiler creates implicit type names in many situations where
-      --  a type is present semantically, but no specific name is present.
-      --  For example:
+      --  The compiler creates implicit type names in many situations where a
+      --  type is present semantically, but no specific name is present. For
+      --  example:
 
       --     S : Integer range M .. N;
 
-      --  Here the subtype of S is not integer, but rather an anonymous
-      --  subtype of Integer. Where possible, the compiler generates names
-      --  for such anonymous types that are related to the type from which
-      --  the subtype is obtained as follows:
+      --  Here the subtype of S is not integer, but rather an anonymous subtype
+      --  of Integer. Where possible, the compiler generates names for such
+      --  anonymous types that are related to the type from which the subtype
+      --  is obtained as follows:
 
       --     T name suffix
 
       --  where name is the name from which the subtype is obtained, using
       --  lower case letters and underscores, and suffix starts with an upper
-      --  case letter. For example, the name for the above declaration of S
-      --  might be:
+      --  case letter. For example the name for the above declaration might be:
 
       --     TintegerS4b
 
@@ -985,11 +983,11 @@ package Exp_Dbug is
    --    x___XRE   for an exception renaming
    --    x___XRP   for a package renaming
 
-   --  The name is fully qualified in the usual manner, i.e. qualified in
-   --  the same manner as the entity x would be. In the case of a package
-   --  renaming where x is a child unit, the qualification includes the
-   --  name of the parent unit, to disambiguate child units with the same
-   --  simple name and (of necessity) different parents.
+   --  The name is fully qualified in the usual manner, i.e. qualified in the
+   --  same manner as the entity x would be. In the case of a package renaming
+   --  where x is a child unit, the qualification includes the name of the
+   --  parent unit, to disambiguate child units with the same simple name and
+   --  (of necessity) different parents.
 
    --  Note: subprogram renamings are not encoded at the present time
 
@@ -1001,17 +999,17 @@ package Exp_Dbug is
 
    --       (y___XE)
 
-   --          i.e. the enumeration type has a single field, whose name
-   --          matches the name y, with the XE suffix. The entity for this
-   --          enumeration literal is fully qualified in the usual manner.
-   --          All subprogram, exception, and package renamings fall into
-   --          this category, as well as simple object renamings.
+   --          i.e. the enumeration type has a single field, whose name matches
+   --          the name y, with the XE suffix. The entity for this enumeration
+   --          literal is fully qualified in the usual manner. All subprogram,
+   --          exception, and package renamings fall into this category, as
+   --          well as simple object renamings.
 
    --    For the object renaming case where y is a selected component or an
    --    indexed component, the literal name is suffixed by additional fields
-   --    that give details of the components. The name starts as above with
-   --    a y___XE entity indicating the outer level variable. Then a series
-   --    of selections and indexing operations can be specified as follows:
+   --    that give details of the components. The name starts as above with a
+   --    y___XE entity indicating the outer level variable. Then a series of
+   --    selections and indexing operations can be specified as follows:
 
    --      Indexed component
 
@@ -1033,14 +1031,14 @@ package Exp_Dbug is
 
    --      Slice
 
-   --        For the slice case, we have two entries. The first is for
-   --        the lower bound of the slice, and has the form
+   --        For the slice case, we have two entries. The first is for the
+   --        lower bound of the slice, and has the form
 
    --          XLnnn
    --          XLe
 
-   --            Specifies the lower bound, using exactly the same encoding
-   --            as for an XS subscript as described above.
+   --            Specifies the lower bound, using exactly the same encoding as
+   --            for an XS subscript as described above.
 
    --        Then the upper bound appears in the usual XSnnn/XSe form
 
@@ -1158,61 +1156,57 @@ package Exp_Dbug is
    --       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.
+   --  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.
+   --  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.
+   --  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.
+   --  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.
+   --  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:
+   --  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.
+   --  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.
+   --  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 := 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 --
@@ -1222,27 +1216,26 @@ package Exp_Dbug is
      (Typ   : Entity_Id;
       Csize : Uint)
       return  Name_Id;
-   --  This function is used in Exp_Pakd to create the name that is encoded
-   --  as described above. The entity Typ provides the name ttt, and the
-   --  value Csize is the component size that provides the nnn value.
+   --  This function is used in Exp_Pakd to create the name that is encoded as
+   --  described above. The entity Typ provides the name ttt, and the value
+   --  Csize is the component size that provides the nnn value.
 
    --------------------------------------
    -- Pointers to Unconstrained Arrays --
    --------------------------------------
 
-   --  There are two kinds of pointers to arrays. The debugger can tell
-   --  which format is in use by the form of the type of the pointer.
+   --  There are two kinds of pointers to arrays. The debugger can tell which
+   --  format is in use by the form of the type of the pointer.
 
    --    Fat Pointers
 
    --      Fat pointers are represented as a struct with two fields. This
    --      struct has two distinguished field names:
 
-   --        P_ARRAY is a pointer to the array type. The name of this
-   --        type is the unconstrained type followed by "___XUA". This
-   --        array will have bounds which are the discriminants, and
-   --        hence are unparsable, but will give the number of
-   --        subscripts and the component type.
+   --        P_ARRAY is a pointer to the array type. The name of this type is
+   --        the unconstrained type followed by "___XUA". This array will have
+   --        bounds which are the discriminants, and hence are unparsable, but
+   --        will give the number of subscripts and the component type.
 
    --        P_BOUNDS is a pointer to a struct, the name of  whose type is the
    --        unconstrained array name followed by "___XUB" and which has
@@ -1251,74 +1244,71 @@ package Exp_Dbug is
    --           LBn (n a decimal integer) lower bound of n'th dimension
    --           UBn (n a decimal integer) upper bound of n'th dimension
 
-   --        The bounds may be any integral type. In the case of an
-   --        enumeration type, Enum_Rep values are used.
+   --        The bounds may be any integral type. In the case of an enumeration
+   --        type, Enum_Rep values are used.
 
-   --      The debugging information will sometimes reference an anonymous
-   --      fat pointer type. Such types are given the name xxx___XUP, where
-   --      xxx is the name of the designated type. If the debugger is asked
-   --      to output such a type name, the appropriate form is "access xxx".
+   --      The debugging information will sometimes reference an anonymous fat
+   --      pointer type. Such types are given the name xxx___XUP, where xxx is
+   --      the name of the designated type. If the debugger is asked to output
+   --      such a type name, the appropriate form is "access xxx".
 
    --    Thin Pointers
 
-   --      The value of a thin pointer is a pointer to the second field
-   --      of a structure with two fields. The name of this structure's
-   --      type is "arr___XUT", where "arr" is the name of the
-   --      unconstrained array type. Even though it actually points into
-   --      middle of this structure, the thin pointer's type in debugging
-   --      information is pointer-to-arr___XUT.
-
-   --      The first field of arr___XUT is named BOUNDS, and has a type
-   --      named arr___XUB, with the structure described for such types
-   --      in fat pointers, as described above.
-
-   --      The second field of arr___XUT is named ARRAY, and contains
-   --      the actual array. Because this array has a dynamic size,
-   --      determined by the BOUNDS field that precedes it, all of the
-   --      information about arr___XUT is encoded in a parallel type named
-   --      arr___XUT___XVE, with fields BOUNDS and ARRAY___XVL. As for
-   --      previously described ___XVE types, ARRAY___XVL has
-   --      a pointer-to-array type. However, the array type in this case
-   --      is named arr___XUA and only its element type is meaningful,
-   --      just as described for fat pointers.
+   --      The value of a thin pointer is a pointer to the second field of a
+   --      structure with two fields. The name of this structure's type is
+   --      "arr___XUT", where "arr" is the name of the unconstrained array
+   --      type. Even though it actually points into middle of this structure,
+   --      the thin pointer's type in debugging information is
+   --      pointer-to-arr___XUT.
+
+   --      The first field of arr___XUT is named BOUNDS, and has a type named
+   --      arr___XUB, with the structure described for such types in fat
+   --      pointers, as described above.
+
+   --      The second field of arr___XUT is named ARRAY, and contains the
+   --      actual array. Because this array has a dynamic size, determined by
+   --      the BOUNDS field that precedes it, all of the information about
+   --      arr___XUT is encoded in a parallel type named arr___XUT___XVE, with
+   --      fields BOUNDS and ARRAY___XVL. As for previously described ___XVE
+   --      types, ARRAY___XVL has a pointer-to-array type. However, the array
+   --      type in this case is named arr___XUA and only its element type is
+   --      meaningful, just as described for fat pointers.
 
    --------------------------------------
    -- Tagged Types and Type Extensions --
    --------------------------------------
 
-   --  A type C derived from a tagged type P has a field named "_parent"
-   --  of type P that contains its inherited fields. The type of this
-   --  field is usually P (encoded as usual if it has a dynamic size),
-   --  but may be a more distant ancestor, if P is a null extension of
-   --  that type.
+   --  A type C derived from a tagged type P has a field named "_parent" of
+   --  type P that contains its inherited fields. The type of this field is
+   --  usually P (encoded as usual if it has a dynamic size), but may be a more
+   --  distant ancestor, if P is a null extension of that type.
 
-   --  The type tag of a tagged type is a field named _tag, of type void*.
-   --  If the type is derived from another tagged type, its _tag field is
-   --  found in its _parent field.
+   --  The type tag of a tagged type is a field named _tag, of type void*. If
+   --  the type is derived from another tagged type, its _tag field is found in
+   --  its _parent field.
 
    -----------------------------
    -- Variant Record Encoding --
    -----------------------------
 
-   --  The variant part of a variant record is encoded as a single field
-   --  in the enclosing record, whose name is:
+   --  The variant part of a variant record is encoded as a single field in the
+   --  enclosing record, whose name is:
 
    --     discrim___XVN
 
-   --  where discrim is the unqualified name of the variant. This field name
-   --  is built by gigi (not by code in this unit). In the case of an
-   --  Unchecked_Union record, this discriminant will not appear in the
-   --  record, and the debugger must proceed accordingly (basically it
-   --  can treat this case as it would a C union).
-
-   --  The type corresponding to this field has a name that is obtained
-   --  by concatenating the type name with the above string and is similar
-   --  to a C union, in which each member of the union corresponds to one
-   --  variant. However, unlike a C union, the size of the type may be
-   --  variable even if each of the components are fixed size, since it
-   --  includes a computation of which variant is present. In that case,
-   --  it will be encoded as above and a type with the suffix "___XVN___XVU"
-   --  will be present.
+   --  where discrim is the unqualified name of the variant. This field name is
+   --  built by gigi (not by code in this unit). For Unchecked_Union record,
+   --  this discriminant will not appear in the record, and the debugger must
+   --  proceed accordingly (basically it can treat this case as it would a C
+   --  union).
+
+   --  The type corresponding to this field has a name that is obtained by
+   --  concatenating the type name with the above string and is similar to a C
+   --  union, in which each member of the union corresponds to one variant.
+   --  However, unlike a C union, the size of the type may be variable even if
+   --  each of the components are fixed size, since it includes a computation
+   --  of which variant is present. In that case, it will be encoded as above
+   --  and a type with the suffix "___XVN___XVU" will be present.
 
    --  The name of the union member is encoded to indicate the choices, and
    --  is a string given by the following grammar:
@@ -1335,15 +1325,15 @@ package Exp_Dbug is
 
    --    R1T4S7S10m
 
-   --  In the case of enumeration values, the values used are the
-   --  actual representation values in the case where an enumeration type
-   --  has an enumeration representation spec (i.e. they are values that
-   --  correspond to the use of the Enum_Rep attribute).
+   --  In the case of enumeration values, the values used are the actual
+   --  representation values in the case where an enumeration type has an
+   --  enumeration representation spec (i.e. they are values that correspond
+   --  to the use of the Enum_Rep attribute).
 
-   --  The type of the inner record is given by the name of the union
-   --  type (as above) concatenated with the above string. Since that
-   --  type may itself be variable-sized, it may also be encoded as above
-   --  with a new type with a further suffix of "___XVU".
+   --  The type of the inner record is given by the name of the union type (as
+   --  above) concatenated with the above string. Since that type may itself be
+   --  variable-sized, it may also be encoded as above with a new type with a
+   --  further suffix of "___XVU".
 
    --  As an example, consider:
 
@@ -1362,23 +1352,22 @@ package Exp_Dbug is
 
    --    V1 : Var;
 
-   --  In this case, the type var is represented as a struct with three
-   --  fields, the first two are "disc" and "m", representing the values
-   --  of these record  components.
+   --  In this case, the type var is represented as a struct with three fields,
+   --  the first two are "disc" and "m", representing the values of these
+   --  record components.
 
-   --  The third field is a union of two types, with field names S1 and O.
-   --  S1 is a struct with fields "r" and "s", and O is a struct with
-   --  fields "t".
+   --  The third field is a union of two types, with field names S1 and O. S1
+   --  is a struct with fields "r" and "s", and O is a struct with fields "t".
 
    ------------------------------------------------
    -- Subprograms for Handling Variant Encodings --
    ------------------------------------------------
 
    procedure Get_Variant_Encoding (V : Node_Id);
-   --  This procedure is called by Gigi with V being the variant node.
-   --  The corresponding encoding string is returned in Name_Buffer with
-   --  the length of the string in Name_Len, and an ASCII.NUL character
-   --  stored following the name.
+   --  This procedure is called by Gigi with V being the variant node. The
+   --  corresponding encoding string is returned in Name_Buffer with the length
+   --  of the string in Name_Len, and an ASCII.NUL character stored following
+   --  the name.
 
    ---------------------------------
    -- Subtypes of Variant Records --
@@ -1405,38 +1394,37 @@ package Exp_Dbug is
    --    V2 : Var (True);
    --    V3 : Var (False);
 
-   --  Here V2 for example is represented with a subtype whose name is
-   --  something like TvarS3b, which is a struct with three fields. The
-   --  first two fields are "disc" and "m" as for the base type, and
-   --  the third field is S1, which contains the fields "r" and "s".
+   --  Here V2, for example, is represented with a subtype whose name is
+   --  something like TvarS3b, which is a struct with three fields. The first
+   --  two fields are "disc" and "m" as for the base type, and the third field
+   --  is S1, which contains the fields "r" and "s".
 
    --  The debugger should simply ignore structs with names of the form
-   --  corresponding to variants, and consider the fields inside as
-   --  belonging to the containing record.
+   --  corresponding to variants, and consider the fields inside as belonging
+   --  to the containing record.
 
    -------------------------------------------
    -- Character literals in Character Types --
    -------------------------------------------
 
-   --  Character types are enumeration types at least one of whose
-   --  enumeration literals is a character literal. Enumeration literals
-   --  are usually simply represented using their identifier names. In
-   --  the case where an enumeration literal is a character literal, the
-   --  name aencoded as described in the following paragraph.
+   --  Character types are enumeration types at least one of whose enumeration
+   --  literals is a character literal. Enumeration literals are usually simply
+   --  represented using their identifier names. If the enumeration literal is
+   --  a character literal, the name aencoded as described in the following
+   --  paragraph.
 
-   --  A name QUhh, where each 'h' is a lower-case hexadecimal digit,
-   --  stands for a character whose Unicode encoding is hh, and
-   --  QWhhhh likewise stands for a wide character whose encoding
-   --  is hhhh. The representation values are encoded as for ordinary
-   --  enumeration literals (and have no necessary relationship to the
-   --  values encoded in the names).
+   --  A name QUhh, where each 'h' is a lower-case hexadecimal digit, stands
+   --  for a character whose Unicode encoding is hh, and QWhhhh likewise stands
+   --  for a wide character whose encoding is hhhh. The representation values
+   --  are encoded as for ordinary enumeration literals (and have no necessary
+   --  relationship to the values encoded in the names).
 
    --  For example, given the type declaration
 
    --    type x is (A, 'C', B);
 
-   --  the second enumeration literal would be named QU43 and the
-   --  value assigned to it would be 1.
+   --  the second enumeration literal would be named QU43 and the value
+   --  assigned to it would be 1.
 
    -----------------------------------------------
    -- Secondary Dispatch tables of tagged types --
@@ -1448,9 +1436,9 @@ package Exp_Dbug is
       Suffix_Index : Int);
    --  Set Name_Buffer and Name_Len to the external name of one secondary
    --  dispatch table of Typ. If the interface has been inherited from some
-   --  ancestor then Ancestor_Typ is such node (in this case the secondary
-   --  DT is needed to handle overriden primitives); if there is no such
-   --  ancestor then  Ancestor_Typ is equal to Typ.
+   --  ancestor then Ancestor_Typ is such node (in this case the secondary DT
+   --  is needed to handle overriden primitives); if there is no such ancestor
+   --  then Ancestor_Typ is equal to Typ.
    --
    --  Internal rule followed for the generation of the external name:
    --
@@ -1464,11 +1452,11 @@ package Exp_Dbug is
    --             External_Name (Typ) + '_' + External_Name (Ancestor_Typ)
    --               + Suffix_Number + 'P'
    --
-   --  Note: We have to use the external names (instead of simply their
-   --  names) to protect the frontend against programs that give the same
-   --  name to all the interfaces and use the expanded name to reference
-   --  them. The Suffix_Number is used to differentiate all the secondary
-   --  dispatch tables of a given type.
+   --  Note: We have to use the external names (instead of simply their names)
+   --  to protect the frontend against programs that give the same name to all
+   --  the interfaces and use the expanded name to reference them. The
+   --  Suffix_Number is used to differentiate all the secondary dispatch
+   --  tables of a given type.
    --
    --  Examples:
    --
@@ -1503,14 +1491,14 @@ package Exp_Dbug is
    ----------------------------
 
    --  If the program is compiled with optimization on (e.g. -O1 switch
-   --  specified), then there may be variations in the output from the
-   --  above specification. In particular, objects may disappear from
-   --  the output. This includes not only constants and variables that
-   --  the program declares at the source level, but also the x___L and
-   --  x___U constants created to describe the lower and upper bounds of
-   --  subtypes with dynamic bounds. This means for example, that array
-   --  bounds may disappear if optimization is turned on. The debugger
-   --  is expected to recognize that these constants are missing and
-   --  deal as best as it can with the limited information available.
+   --  specified), then there may be variations in the output from the above
+   --  specification. In particular, objects may disappear from the output.
+   --  This includes not only constants and variables that the program declares
+   --  at the source level, but also the x___L and x___U constants created to
+   --  describe the lower and upper bounds of subtypes with dynamic bounds.
+   --  This means for example, that array bounds may disappear if optimization
+   --  is turned on. The debugger is expected to recognize that these constants
+   --  are missing and deal as best as it can with the limited information
+   --  available.
 
 end Exp_Dbug;