dwarf2 abort with block extern decl for inline function

[Jim Wilson <wilson at cygnus dot com>]

This testcase hits an abort in add_abstract_origin_attribute when compiled
with -O -gdwarf-2.

inline int
foo (int i)
{
  return i;
}

static void
bar ()
{
  int foo ();
  signed int foo ();
}

This was broken by this change:

2000-04-25  Jason Merrill  <jason@casey.cygnus.com>

	* dwarf2out.c (gen_subprogram_die): The class-scope declaration DIE
	is the primary DIE for a member function.
	(gen_decl_die): Call set_decl_origin_self here.

The patch actually does something a bit different than the ChangeLog entry
describes.  It changes the conditions in which gen_abstract_function is
called.  Before the patch, we always called gen_abstract_function if
decl_ultimate_origin returns non-null.  Now, we call gen_abstract_function
apparently only if we have a C++ member function reference.  This means
that if we have a block extern reference to a C inline function, there is
no die for the abstract instance of the function when we try to emit debug
info for the declaration, and thus we hit the abort.  The dwarf2 code
deliberately tries to emit debug info for block extern references, so this
should work.

This happens to work by accident in most cases, because duplicate_decls
will set DECL_IGNORED_P if different_binding_level is true.  Thus if we
have one duplicate decl, the testcase works.  But if we have two dupliacate
decls, then DECL_IGNORED_P is not copied from olddecl to newdecl for the
second one, and then DECL_IGNORED_P gets clobbered when we copy newdecl to
olddecl.

One could perhaps argue that this is a bug in duplicate_decls.  If we
copy DECL_IGNORED_P from olddecl to newdecl, then this problem goes away.
However, I still think that there is a flaw in dwarf2out.c.  It shouldn't
be relying on duplicate_decls to set DECL_IGNORED_P.  In gen_decl_die,
in the case FUNCTION_DECL, first we have
	DECL_CONTEXT (decl) == NULL_TREE
when we decide whether to emit debug info, then we have
	! class_scope_p (context_die)
when we decide whether to emit the abstract instance.  The first test is more
general than the second, so we end up unhandled cases.  I think those
two tests need to be the same, but I'm not sure which test is the correct one.
I suspect the first test is the right one.

Jim