On Tue, Sep 11, 2012 at 5:32 PM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Tue, 11 Sep 2012, Dehao Chen wrote: > >> Looks like we have two choices: >> >> 1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t) > > This will actually not work correctly in some cases. The problem is, if > the prevailing decl is already part of another chain (say in another > block_var list) you would break the current chain. Hence block vars need > special handling in the lto streamer (another reason why tree_chain is not > the most clever think to use for this chain). This problem area needs to > be solved somehow if block info is to be preserved correctly.
Well. The issue is that at present we stream BLOCKs in the function section via its DECL_INTIAL. Which means we _never_ should get a non-prevailing DECL in BLOCK_VARS. You need to debug why that doesn't work anymore. Possibly the BLOCK leaks into decls it should not leak to via the location mechanism? >> 2. Don't stream out block info for LTO, and still call LTO_NO_PREVAIL >> (TREE_CHAIN (t)). > > That's also a large hammer as it basically will mean no debug info after > LTO :-/ Sigh, at this point I have no good solution that doesn't involve > quite some work, perhaps your hack is good enough for the time being, > though I hate it :) It hides a bug. If we replace anything in BLOCK_VARS then the risk is that you generate an infinite chain in some BLOCK_VARS list and thus get infinite loops somewhere in the compiler. So, no, that's not an option. Richard. > > Ciao, > Michael.