Advise needed on varasm.c constant recording bug

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

This came up with an Ada program in GCC 2.8.1.

There was a test case that had a series of procedures that looked
identical except they were operating on different object types.  What they
were doing was assigning a CONSTRUCTOR to something.

When we compare tree constants for equality in varasm.c, we hash the
address of the type and record that address.

But these types were function-local and so were in the function obstack.
It so happened, since these functions were identical, that each of the types
got assigned to the *same address*.  Since the values of each field in the
record were identical and the types *looked* identical, it used the same
RTL symbol for all the constants, which is wrong, since they were for
different records!

I'm somewhat of a loss as to how to fix it for GCC 2.8.1, though I may
just kludge it, but the real question is do we want to do something about
it for GCC 3.1.

It can still happen, since GC doesn't know about those pointers buried in
the constant descriptors, though it's going to be *much* rarer since
it depends on when GC occurs, not on when memory for obstacks gets freed.
I strongly doubt I could actually create a test case that shows it, but it's
clearly a potential bug.

We *could* fix it by teaching GC to look inside the constant descriptors,
but I think that's a mess.  Indeed, we don't *need* those constant
descriptors anymore.  We can simply keep a hash table of the tree nodes for
the constants themselves and let GC know about it.  Indeed, this was on
my list of things to do for 3.1, but it didn't get done by December 15.

This is a bit of a large change to make at this point in the development
process, so I hesitate to make it for something that's just a theoretical
bug, but I wanted to get some input from others here.