This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
internal compiler error at dwarf2out.c:8362
- From: Martin Koegler <mkoegler at auto dot tuwien dot ac dot at>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 12 Apr 2005 14:21:15 +0200
- Subject: internal compiler error at dwarf2out.c:8362
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
e9925248@stud4.tuwien.ac.at