This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: internal compiler error at dwarf2out.c:8362
Martin Koegler wrote:
I added to the i386 version the following code (using a unmodified gcc for the rest):
With this change, I can reproduce the problem.
I noticed that I get a failure for all types, not just array types.
This is different than what you described earlier, but perhaps the
difference is that we don't have the questionable code to create new
types here.
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.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com