[PATCH] Combine location with block using block_locations

[Richard Guenther]

On Wed, Sep 12, 2012 at 2:14 PM, Michael Matz <matz@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.