This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/5] Altera Nios II: dwarf generation fix

On 2013/4/19 12:56 AM, Cary Coutant wrote:
> On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang <> wrote:
>> This patch was a fix by Julian which corrected a HOST_BITS_PER_WIDE_INT
>> host dependency in dwarf generation. Nios II does not have
>> need_64bit_hwint switched on during configuring, and ran into GDB test
>> FAILs originating from this problem.
>> 2013-04-18  Julian Brown  <>
>>         * dwarf2out.c (gen_enumeration_type_die): Fix
>>         HOST_BITS_PER_WIDE_INT dependency behavior in enumeration type
>>         DIE generation.
> +  if (host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
> +      && (simple_type_size_in_bits (TREE_TYPE (value))
> +  <= HOST_BITS_PER_WIDE_INT || host_integerp (value, 0)))
>      /* DWARF2 does not provide a way of indicating whether or
>         not enumeration constants are signed or unsigned.  GDB
>         always assumes the values are signed, so we output all
>         values as if they were signed.  That means that
>         enumeration constants with very large unsigned values
>         will appear to have negative values in the debugger.  */
> +    add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
> +  else
> +    /* Enumeration constants may be wider than HOST_WIDE_INT.  Handle
> +       that here.  */
> +    add_AT_double (enum_die, DW_AT_const_value,
> +                   TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW (value));
> I'm not sure I understand the logic here. I'd think either the value
> fits in a signed HOST_WIDE_INT, and we use add_AT_int, or it doesn't,
> and we use add_AT_double:
>   if (host_integerp (value, 0))
>     add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
>   else
>     add_AT_double (enum_die, DW_AT_const_value,
>                    TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW (value));
> Why wouldn't that work? I'd think this would even eliminate the need
> for the comment about signed vs. unsigned.
> -cary

I think Julian might be able to fill clearer, but IIUC, if you use
host_integer(value,0) as the test, while functionally also correct, for
values like:

TREE_INT_CST_HIGH (value) == 00000000...
TREE_INT_CST_LOW (value)  == 1xxxxxxx...

you will end up placing it as a double, even if TREE_TYPE (value) is
something within 32-bits, which you can actually place as an 'int'. In
other words, the more complex condition saves a bit of dwarf size.

Julian, can you comment further?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]