DWARF: Set enum type "flag_enum" and "unsigned" flags at type creation.

Consider the following Ada code:

   --  An array whose index is an enumeration type with 128 enumerators.
   type Enum_T is (Enum_000, Enum_001, [...], Enum_128);
   type Table is array (Enum_T) of Boolean;

When the compiler is configured to generate pure DWARF debugging info,
trying to print type Table's description yields:

    ptype pck.table
    type = array (enum_000 .. -128) of boolean

The expected output was:

    ptype pck.table
    type = array (enum_000 .. enum_128) of boolean

The DWARF debugging info for our array looks like this:

    <1><44>: Abbrev Number: 5 (DW_TAG_array_type)
       <45>   DW_AT_name        : pck__table
       <50>   DW_AT_type        : <0x28>
    <2><54>: Abbrev Number: 6 (DW_TAG_subrange_type)
       <55>   DW_AT_type        : <0x5c>
       <59>   DW_AT_lower_bound : 0
       <5a>   DW_AT_upper_bound : 128

The array index type is, by construction with the DWARF standard,
a subrange of our enumeration type, defined as follow:

    <2><5b>: Abbrev Number: 0
    <1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type)
       <5d>   DW_AT_name        : pck__enum_t
       <69>   DW_AT_byte_size   : 1
    <2><6b>: Abbrev Number: 8 (DW_TAG_enumerator)
       <6c>   DW_AT_name        : pck__enum_000
       <7a>   DW_AT_const_value : 0
    [etc]

Therefore, while processing these DIEs, the array index type ends
up being a TYPE_CODE_RANGE whose target type is our enumeration type.
But the problem is that we read the upper bound as a negative value
(-128), which is then used as is by the type printer to print the
array upper bound. This negative value explains the "-128" in the
output.

To understand why the range type's upper bound is read as a negative
value, one needs to look at how it is determined, in read_subrange_type:

  orig_base_type = die_type (die, cu);
  base_type = check_typedef (orig_base_type);
  [... high is first correctly read as 128, but then ...]
  if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
    high |= negative_mask;

The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED
is not set. And the reason for that is because the base_type was only
partially constructed during the call to die_type. While the enum
is constructed on the fly by read_enumeration_type, its flag_unsigned
flag is only set later on, while creating the symbols corresponding to
the enum type's enumerators (see process_enumeration_scope), after
we've already finished creating our range type - and therefore too
late.

My first naive attempt at fixing this problem consisted in extracting
the part in process_enumeration_scope which processes all enumerators,
to generate the associated symbols, but more importantly set the type's
various flags when necessary. However, this does not always work well,
because we're still in the subrange_type's scope, and it might be
different from the scope where the enumeration type is defined.

So, instead, what this patch does to fix the issue is to extract
from process_enumeration_scope the part that determines whether
the enumeration type should have the flag_unsigned and/or the
flag_flag_enum flags set. It turns out that, aside from the code
implementing the loop, this part is fairly independent of the symbol
creation. With that part extracted, we can then use it at the end
of our enumeration type creation, to produce a type which should now
no longer need any adjustment.

Once the enumeration type produced is correctly marked as unsigned,
the subrange type's upper bound is then correctly read as an unsigned
value, therefore giving us an upper bound of 128 instead of -128.

gdb/ChangeLog:

        * dwarf2read.c (update_enumeration_type_from_children): New
        function, mostly extracted from process_structure_scope.
        (read_enumeration_type): Call update_enumeration_type_from_children.
        (process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned
        and flag_flag_enum fields.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
Add comment in dwarf2read.c::read_subrange_type

This comment explains why we sometimes sign-extend the range type
bounds when we normally shouldn't have to.

gdb/ChangeLog:

        * dwarf2read.c (read_subrange_type): Add comment.