more on duplicate decls

[Kenneth Zadeck]

I have been trying to cleanup the location where the persistent ipa 
information is stored.

The original way that I did this was that I had a field in the var_ann 
structure that pointed to the ipa_information. 

Now that danny has reorganized the decls, the plan was to just add a 
field to the function_decl.

Danny has suggested that if I was going to add such a field, it should 
be a pointer to the cgraph_node and then store the persistent ipa 
information there.

I noticed that if I did this, there should be a lot of stuff that could 
fall away.  There would be no need to have the hash table that points 
from function_decls to cgraph nodes as well as there was no need for the 
master_clone field since the cgraph node that the decl pointed to would 
be just this good.  All of this sounds great... smaller,  faster.

This has not gone as easy as I had hoped.  Danny found the first 
stumbling block yesterday that the c  decl merging needed to be enhanced.

The second bug appears to be harder.  In c++, there really can be 
multiple function_decls with the same uid.

The kludge to handle them is documented in cp/name-lookup.c around line 
670 and one test case to generate them is in 
gcc/testsuite/g++.dg/opt/inline2.C.
There are several ways to go about fixing this:  One is to just abandon 
my fix and let others (such as the code sourcery people deal with it 
when they go to build a real symbol table.)

It seems like a better way is to build a table of merges that need to be 
done and find some place after the c++ front end is finished but before 
the cgraph gets built and do one scan of the code and replace all of the 
offending decls. 

Does such a location exist?

Is this the correct plan?

Kenny