> On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote: > > On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote: > > > So... I've been getting my feet wet with LTO and debugging and I noticed a > > > seemingly unrelated yet annoying problem. On x86-64, > > > gcc.dg/guality/pr48437.c fails when run in LTO mode. > > > > > > Eh, sorry I can't actually answer your question but, eh... > > > > Isn't the only real solution: to generate this kind of DIEs earlier > > (maybe already immediately after parsing) and stream them? > > > > Otherwise, how can this possibly be made to work with multi-language LTO? > > > > It seems to me that only the lowest-level DWARF (things we don't know > > about until RTL, like CFI) should be done at link time. Things like > > scoping and types are language dependent and have to be generated > > before streaming. > > > > Again, sorry for not actually being helpful - just a thought ;-) > > The plan is indeed to generate as much DWARF as possible early. > But, BLOCKs are something which if you throw away during compilation like > LTO does right now will never work properly, because while some minimal > DWARF tree can be created for it early, for the lexical block to be useful > you need > to track on which exact instructions the lexical block is in scope and on > which it is not.
We do get blocks at LTO and variables in BLOCK_VARs list, just global decls are skipped (because they are linked by chain pointer and one decl thus can not appear in multiple lists and decl merging will make that happen) I would expect the early DWARF to already contains its representation of BLOCK_VARS at least for the global decls. If that is undobale we can always link BLOCK_VARs by vector instead of tree chain and fix this issue. Honza > > Jakub
