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. Ciao, Michael.
