Re: PATCH for type hash-table

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    This oddity has gone unnoticed because we check that a newly created
    type is permanent that it is TREE_PERMANENT before adding it to the
    hash table.  That does not actually ensure that the current_obstack is
    the permanent_obstack, however, since `make_node' will always put a
    type on the saveable_obstack or permanent_obstack, regardless of the
    current_obstack.  Thus, if the current_obstack is (say) the
    temporary_obstack and the saveable_obstack is the permanent_obstack,
    then we can end up with a non-permanent hash-table entry.

    I consider this to be an "obvious bug", but I'll hold off checking
    this in for a little bit in case somebody thinks otherwise.

I don't consider it a bug since, as you say, it's been there forever:
it merely means we have to be careful.  I have indeed run into bugs
relating to type_hash_add, when it's getting called while in some
other allocation, but your patch won't fix that case since it's
usually the case that some *other* type pointed to by that type is in
the wrong obstack as well.

I'm not sure this change is what I'd consider *wrong*, but I don't
think it does much.  Perhaps an alternate approach is to add an abort
if not doing permanent allocation?