On Wed, Sep 12, 2012 at 2:14 PM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Wed, 12 Sep 2012, Richard Guenther wrote: > >> > 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. > > The assert that triggers tests that there's no var_decl in TREE_CHAIN. > It doesn't test that it's a prevailing decl. So we could assert that > instead of the current check. > >> >> 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. > > That's what I said for using SET_PREVAIL. But his hack would specifically > not replace anything in TREE_CHAIN (and hence BLOCK_VARS), and indeed not > check anything either.
Hm, but we shouldn't end up streaming any BLOCKs at this point (nor local TYPE_DECLs). Those are supposed to be in the local function sections only where no fixup for prevailing decls happens. Richard. > > Ciao, > Michael.
