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]