This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]