Fixup INTEGER_CST

[Richard Guenther]

On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > Hi,
>> > I added a santy check that after fixup all types that lost in the merging are
>> > really dead.  And it turns out we have some zombies around.
>> >
>> > INTEGER_CST needs special care because it is special cased by the streamer.  We also
>> > do not want to do inplace modificaitons on it because that would corrupt the hashtable
>> > used by tree.c's sharing code
>> >
>> > Bootstrapped/regtested x86_64-linux, OK?
>>
>> No, I don't think we want to fixup INTEGER_CSTs this way.  Instead we
>> want to fixup
>> them where they end up used unfixed.
>
> Erm, I think it is what the patch does?

Ah, indeed.

> It replaces pointers to integer_cst with type that did not survive by pointer
> to new integer_cst. (with the optimization that INTEGER_CST with overflow
> is changed in place because it is allowed to do so).

Btw ...

>> > @@ -1526,6 +1549,11 @@ lto_ft_type (tree t)
>> >    LTO_FIXUP_TREE (t->type_non_common.binfo);
>> >
>> >    LTO_FIXUP_TREE (TYPE_CONTEXT (t));
>> > +
>> > +  if (TREE_CODE (t) == METHOD_TYPE)
>> > +    TYPE_METHOD_BASETYPE (t);
>> > +  if (TREE_CODE (t) == OFFSET_TYPE)
>> > +    TYPE_OFFSET_BASETYPE (t);

that looks like a no-op to me ... (both are TYPE_MAXVAL which
is already fixed up).

Thus, ok with removing the above hunk.

Thanks,
Richard.

>> >  }
>> >
>> >  /* Fix up fields of a BINFO T.  */