Re: [lto]: merge from trunk

["Bill Maddox" <maddox at google dot 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