This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [lto]: merge from trunk
- From: "Bill Maddox" <maddox at google dot com>
- To: "Kenneth Zadeck" <zadeck at naturalbridge dot com>
- Cc: "Diego Novillo" <dnovillo at google dot com>, "Ollie Wild" <aaw at google dot com>, "Hubicha, Jan" <jh at suse dot cz>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "Kai Tietz" <kai dot tietz at onevision dot com>
- Date: Mon, 14 Jul 2008 00:06:59 -0700
- Subject: Re: [lto]: merge from trunk
- References: <48754454.6030503@naturalbridge.com>
I've done some analysis of this bug. The failure appears to be caused
by the following lines in builtings.c (std_canonical_list_type):
wtype = va_list_type_node;
htype = type;
/* ... */
if (TYPE_MAIN_VARIANT (wtype) == TYPE_MAIN_VARIANT (htype))
return va_list_type_node;
Here, we are expecting the "well-known" type va_list_type_node,
stashed away in a global variable during compiler initialization by
both cc1 and lto1, to share substructure (the TYPE_MAIN_VARIANT) with
that of a type that has been internalized from a stream. Poking
around in GDB shows that wtype and htype, and TYPE_MAIN_VARIANT(wtype)
and TYPE_MAIN_VARIANT(htype) are similar, but they are not the same
object. The streamer goes to some trouble to properly share the
well-known objects themselves, but all bets are off for objects
reachable from the same that are not also well-known objects. (I use
the term "well-known object" to refer to those objects for which
references are kept in the global_trees array.) At this point, it's
not clear to me whether the solution is implement better sharing or
whether the check for pointer equality needs to be relaxed. One
inconsistency I observe is that "sizes-gimplified" is set on
va_list_type_node when preload_common_nodes is run during output. I'm
sure this is not the case for the type reconstructed on the input
side, at least initially. In any case, I will continue to investigate
this.
--Bill