Re: [PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

[Richard Guenther <rguenther@suse.de>]

On Fri, 8 Apr 2011, Jakub Jelinek wrote:

> On Fri, Apr 08, 2011 at 01:58:14PM -0400, Jason Merrill wrote:
> > On 04/05/2011 10:19 AM, Jakub Jelinek wrote:
> > >i686-linux LTO bootstrap currently fails, because in one partition
> > >we emit .Ldebug_info0 label twice.  The problem is that
> > >resolve_addr for call_site support attempts to force_decl_die external
> > >function decls, and at least with LTO that in turn can attempt
> > >to create new type DIEs, in this case an enumeration with context_die
> > >being NULL.  Unfortunately the code to add proper parents to limbo nodes
> > >is done right before resolve_addr (and should be done there, so that
> > >resolve_addr reaches all the needed DIEs).
> > >
> > >+/* Traverse the limbo die list, and add parent/child links.  The only
> > >+   dies without parents that should be here are concrete instances of
> > >+   inline functions, and the comp_unit_die.  We can ignore the comp_unit_die.
> > >+   For concrete instances, we can get the parent die from the abstract
> > >+   instance.  */
> > 
> > Sounds like this comment needs to be updated if there can be types
> > on the list as well.
> 
> On a closer look, this seems to be because LTO messes up types terribly,
> struct cpp_options's lang field doesn't have enum c_lang type, but
> enum prec whose TYPE_CONTEXT is c_parser_binary_expression
> function from c_parser.c.  So when trying to create DIE for cpp_options
> and stuff in it we end up with the surprising limbo die.
> Therefore, I'm withdrawing my patch and will look into this mess on Monday.

We are definitely unifying enum types too eagerly.  It's on my TODO
to fix that, but it had low priority sofar.

Richard.