gcc.c-torture/unsorted/loop386.c fails on sh-elf

[Alexandre Oliva]

sh-elf-gcc fails to compile loop386.c with -O3 -g.  The problem is
that the implicit declaration of bar() within foo() is never emitted,
but a copy of the implicit declaration makes it to baz(), when foo()
is inlined.  The copy has the original declaration as its abstract
origin, but since there isn't any die for the original declaration,
add_abstract_origin_attribute(), called by gen_subprogram_die() while
processing the copied decl, dies because lookup_decl_die() returns
NULL for the original decl.

I've got a patch that arranges for us to not call
add_abstract_origin_attribute() from gen_subprogram_die()
(dwarf2out.c:9796) if lookup_decl_die() returns NULL for a function
declaration, but I'm not sure that's the right thing to do.

I'm particularly curious about why we never get to process the
original implicit declaration of bar() in gen_decl_die().  For some
reason, decls_for_scope() doesn't find any nested block when
processing foo()'s outer_scope, so it never gets a chance to generate
a die for the original declaration of bar().  Not that this would be
of any help.  The die wouldn't be registered with
equate_decl_number_to_die() because it has no context and it isn't
abstract (dwarf2out.c:9893), so we'd have crashed anyway when
processing the copy of the decl.

This patch can't possibly break anything that is currently working
(we'd crash when the conditions of the new test aren't met), but since
my understanding of debugging formats is close to zero, I must ask: is
it ok to skip this function call when it would crash?  I.e., is this
ok to install?