internal compiler error at dwarf2out.c:8362

[Martin Koegler]

I'm working on a GCC port and hit the error

x.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8362

while compiling 

typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));

with dwarf-2 debugging information. The eeprom attribute is defined so:

static tree
m68hc05_handle_eeprom_attribute (tree * node, tree name,
                                 tree args ATTRIBUTE_UNUSED,
                                 int flags ATTRIBUTE_UNUSED,
                                 bool * no_add_attrs)
{
  if (DECL_P (*node))
    {
      if (TREE_CODE (*node) == TYPE_DECL)
        {
          /* This is really a decl attribute, not a type attribute,
             but try to handle it for GCC 3.0 backwards compatibility.  */

          tree type = TREE_TYPE (*node);
          tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
          tree newtype = build_type_attribute_variant (type, attr);

          TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type);
          TREE_TYPE (*node) = newtype;
        }
    }
  return NULL_TREE;
}

const struct attribute_spec m68hc05_attribute_table[] = {
  /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */
  {"eeprom", 0, 0, false, true, false, m68hc05_handle_eeprom_attribute},
  {NULL, 0, 0, false, false, false, NULL}
};

Without dwarf-2 debugging, the file compiles.

Internal, the type looks so, when the function is called, which aborts:

Breakpoint 1, modified_type_die (type=0xb7f51288, is_const_type=0, 
is_volatile_type=0, context_die=0xb7f6bac4)
    at ../.././gcc/dwarf2out.c:8258
8258      enum tree_code code = TREE_CODE (type);
(gdb) call debug_tree(type)
 <array_type 0xb7f51288 GROUP9_T
    type <integer_type 0xb7f081b0 unsigned char asm_written public unsigned QI
        size <integer_cst 0xb7eff0f0 constant invariant 8>
        unit size <integer_cst 0xb7eff108 constant invariant 1>
        align 8 symtab -1208530080 alias set -1 precision 8 min <integer_cst 
0xb7eff168 0> max <integer_cst 0xb7eff180 255>
        pointer_to_this <pointer_type 0xb7f140d8>>
    BLK
    size <integer_cst 0xb7eff0c0 type <integer_type 0xb7f080d8 bit_size_type> 
constant invariant 24>
    unit size <integer_cst 0xb7eff018 type <integer_type 0xb7f0806c short 
unsigned int> constant invariant 3>
    align 8 symtab 0 alias set -1
    attributes <tree_list 0xb7f77438
        purpose <identifier_node 0xb7f74bc8 eeprom>>
    domain <integer_type 0xb7f08000
        type <integer_type 0xb7f0806c short unsigned int public unsigned 
sizetype HI
            size <integer_cst 0xb7eff1f8 constant invariant 16>
            unit size <integer_cst 0xb7eff210 constant invariant 2>
            align 8 symtab -1208530132 alias set -1 precision 16 min 
<integer_cst 0xb7eff240 0> max <integer_cst 0xb7eff1e0 65535>>
        HI size <integer_cst 0xb7eff1f8 16> unit size <integer_cst 0xb7eff210 2>
        align 8 symtab 0 alias set -1 precision 16 min <integer_cst 0xb7eff090 
0> max <integer_cst 0xb7eff210 2>>>

The GCC core is gcc version 4.1.0 20050412 (experimental).

The bug only happens, if the base type of the second typedef is an array.

As I have not found the use of a port specific type attribute in GCC, I don't 
know,
how I can reproduce it on a official GCC port.

As I have not changed the tree based core and debugging output, the bug should 
be also present 
in the current CVS version.

Any ideas, how to handle this bug?

mfg Martin Kögler
[EMAIL PROTECTED]