PATCH rewrite duplicate_decls to not modify olddecl (fixes gcc/12336)

[Per Bothner]

Daniel Jacobowitz wrote:

> The most likely cause of this is that the dwarf2 writer emits
> information for abstract instances.  This patch overloads that field to
> mean something completely different for C than its normal C++ meaning. 
> If its use overlaps with the C++ frontend's use, there will be more
> problems; if not dwarf2out should be taught when to NOT walk
> DECL_ABSTRACT_ORIGIN.

It's probably possible to add extra DECL_HAS_DUPLICATE checks -
if DECL_HAS_DUPLICATE(NODE), then we may not want to get the
DECL_ABSTRACT_ORIGIN.  This would be best done by somebody
who understandinsg dwarf2out.c and inlining better than I do.

As mentioned, I'm not very confident that DECL_ABSTRACT_ORIGIN
is the appropriate chaining mechanism to use.  In some way it's
the opposite of the result of inlining:  When inlining there
is a single source decl/block/type which becomes multiple
"cloned" decl/block/type nodes each of which have them own rtl.
The result of duplicate_decls are multiple source decls that
are merged to a combined decl and that has a single runtime
object (rtl).

A cleaner mechanism might be to loop up the decl in the symbol
table, and see if there is a newer merged decl.  However, the
symbol table is only availabe to the front-end, not the
backend which needs it to find the rtl.

Or maybe a hybrid between the old and proposed mechanism makes
sense:  Place the DECL_RTL in the olddecl, while otherwise
putting new information in the newdecl.

What complicates the issue are nested extern declarations.
The original implementation used TREE_CHAIN to link from the
old decl to the new decl.  This only works if both are in the
same scope, and specially nested externs cause a problem.  However,
we can create a dummy toplevel extern, and have the nexted one
point to that, perhaps using DECL_ABSTRACT_ORIGIN.  I.e. instead
of poplevel "promoting" a nested extern (and setting C_DECL_INVISIBLE),
we'd create a new decl at toplevel (with C_DECL_INVISIBLE set),
and have he nested extern point to that using DECL_ABSTRACT_ORIGIN.
Then to find the "real" DECL_RTL, we follow DECL_ABSTRACT_ORIGIN
to get to the toplevel, and then TREE_CHAIN from then on.

Conclusion:  There are various ideas to pursue, but it isn't
obvious the best way to do that is clean and efficient.
The easiest is probably some variant of my first solution.

Since C++ has similar issues, it would be helpful to get input
from someone who better understands how C++ handles naming,
specifically the interaction between forward (extern/static)
declarations and scoping.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/