This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Sat, Jan 27, 2001 at 06:37:20PM -0200, Alexandre Oliva wrote:
> 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?

The testcase also fails with -O3 -g for mips-sgi-irix6.5.

Mark Mitchell (mark@codesourcery.com) and I talked about this test
case.  Here are _my_ notes about what he suggested.
decl_ultimate_origin(bar()'s decl) should be NULL because bar() =
puts(), which even though inlined, should have only one die.  If this
is NULL, he conjectures that gcc/dwarf2out.c:gen_decl_die()'s case
TYPE_DECL's second if statement's conditional should fail.

I have deferred fixing this because I do not know how to implement
this.

****************

By the way, several mips-sgi-irix6.5 "-O3 -g" and "-O3
-fomit-frame-pointer" gcc test case failures such as
gcc.c-torture/compile/920723-1.c and gcc.c-torture/execute/930106-1.c
have been fixed.  I will check in the patch as soon as I receive
permission.

Hoping this helps,
Jeffrey D. Oldham
oldham@codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]