The dwarf2 output for a type attribute for an array fails.
Eg:
$cat x.c
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));
$./cc1 --version
GNU C version 4.1.0 20050416 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050302 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$./cc1 -g x.c
x.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8362
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
The eeprom attribute was defined in the following way:
[EMAIL PROTECTED]:/tmp/gcc/gcc]$cvs diff -u config/i386/i386.c
Index: config/i386/i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.808
diff -u -r1.808 i386.c
--- config/i386/i386.c 12 Apr 2005 01:46:28 -0000 1.808
+++ config/i386/i386.c 16 Apr 2005 12:37:52 -0000
@@ -1608,9 +1608,19 @@
#endif
}
+
+static tree
+m68hc05_handle_eeprom_attribute (tree * node, tree name,
+ tree args ATTRIBUTE_UNUSED,
+ int flags ATTRIBUTE_UNUSED,
+ bool * no_add_attrs)
+{
+ return NULL_TREE;
+}
/* Table of valid machine attributes. */
const struct attribute_spec ix86_attribute_table[] =
{
+ {"eeprom", 0, 0, false, true, false, m68hc05_handle_eeprom_attribute},
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */
/* Stdcall attribute says callee is responsible for popping arguments
if they are not variable. */
James E Wilson said about the problem:
I debugged this a bit more. The situation seems to be this:
1) We create a first array type when we parse the array decl in the first line
(build_array_type).
2) We create a second array type when handling the typedef
(clone_underlying_type). This one gets TYPE_NAME set to the typedef, and
DECL_ORIGINAL_TYPE of the typedef points to the first one.
3) We create a third array type when parsing the attributes. See the call to
build_type_attribute_variant in attribs.c. This is a complete copy, so it still
has the GROUP9_T TYPE_NAME.
4) We create a fourth array type when handling the second typedef. This gets
the TYPE_NAME EGROUP9_T, and the typedef has DECL_ORIGINAL_TYPE set to point to
the third array type.
When we emit debug info, we emit debug info for the types used by the typedefs,
which are the second and fourth one. The debug info for the second one is OK.
The debug info for the fourth one runs into trouble. We follow
DECL_ORIGINAL_TYPE to get the third array type, and then we follow TYPE_NAME to
get the second array type, and then we notice that we already emitted debug info
for this type. After we return, we double check to make sure we have debug info
for this type, and fail, because this is not the same array type as we emitted
earlier.
I think the broken type is the 3rd one. I mentioned in an earlier message that
you had two types with the same TYPE_NAME which was wrong. This is happening in
build_type_attribute_variant. Clearing TYPE_NAME here seems to solve the
problem, though I haven't done any testing to see if this is safe.
Maybe a bug report to keep track of this info would be useful.
--
Summary: internal compiler error at dwarf2out.c:8362
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21106
