Re: [RFA/DWARF] Set enum type "flag_enum" and "unsigned" flags at type creation.

[Joel Brobecker <brobecker@adacore.com>]

> So, this patch doesn't show any regressions in the testsuite:
> 
> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
> index 54c538a..0b5de99 100644
> --- a/gdb/dwarf2read.c
> +++ b/gdb/dwarf2read.c
> @@ -14303,7 +14303,6 @@ read_subrange_type (struct die_info *die, struct dwarf2_cu *cu)
>    LONGEST low, high;
>    int low_default_is_valid;
>    const char *name;
> -  LONGEST negative_mask;
>  
>    orig_base_type = die_type (die, cu);
>    /* If ORIG_BASE_TYPE is a typedef, it will not be TYPE_UNSIGNED,
> @@ -14433,13 +14432,6 @@ read_subrange_type (struct die_info *die, struct dwarf2_cu *cu)
>  	}
>      }
>  
> -  negative_mask =
> -    (LONGEST) -1 << (TYPE_LENGTH (base_type) * TARGET_CHAR_BIT - 1);
> -  if (!TYPE_UNSIGNED (base_type) && (low & negative_mask))
> -    low |= negative_mask;
> -  if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
> -    high |= negative_mask;
> -

I finally had some time to test this patch, and unfortunately,
it does introduce some regression (in Ada). For instance in
homonym.exp:

   type Integer_Range is new Integer range -100 .. 100;
   subtype Local_Type is Integer_Range;

This is what GDB would print afterwards:

    (gdb) ptype local_type
    type = range 4294967196 .. 100

The lower bound should be -100. The debugging info is generated
as follow:

 <2><80>: Abbrev Number: 2 (DW_TAG_subrange_type)
    <81>   DW_AT_lower_bound : 0xffffff9c
    <85>   DW_AT_upper_bound : 100
    <86>   DW_AT_name        : (indirect string, offset: 0x76): homonym__get_value__local_type___XDLU_100m__100
    <8a>   DW_AT_type        : <0x37>

And the corresponding abbrev gives the form:

   2      DW_TAG_subrange_type    [no children]
    DW_AT_lower_bound  DW_FORM_data4
    DW_AT_upper_bound  DW_FORM_data1
    DW_AT_name         DW_FORM_strp
    DW_AT_type         DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0

It's the dreaded DW_FORM_dataN form... And unfortunately, I get the same
representation with pre-versions of GCC 4.9, so it looks like we're not
going to be able to remove that bit anytime soon :-(.

I'll add a comment in the code...

-- 
Joel