From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Wilson <wilson@cygnus.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: wilson@redhat.com, schwab@suse.de, gcc@gcc.gnu.org
Subject: Re: Bootstrap failure of gcc-ss-20010409 in ia64 
Date: Sat, 14 Apr 2001 02:01:00 -0000
Message-id: <200104140901.CAA05718@wilson.cygnus.com>
References: <200104140259.TAA32201@wilson.cygnus.com>
X-SW-Source: 2001-04/msg00653.html

My libffi problems are because it has been too long since I last did a cvs co
on my main gcc tree.  I normally just do a cvs update, but that doesn't give
you new directories.  After doing a cvs co to get new directories, libffi now
configures and builds as it should.  There are two libffi build problems, but
both are trivial to fix.  I have patches for both, but have not tested them
yet.

Meanwhile, I've spent about 4 hours looking at the dwarf2out.c abort.
Mostly all I accomplished was to remember how it works, but I did learn a
few things.

The problem is with <var_decl 0x401f4ea0 __exception_info> which is nested
inside a base_ctor function.  This var_decl has an abstract origin of
<var_decl 0x401d5f08 __exception_info> which has a context of
<function_decl 0x401b8ea0 _M_refcopy>.  When we try to add an abtract_origin
attribute pointing at the 0x401d5f08 decl, we first call dwarf2out_abstract_
function on _M_refcopy.  Unfortunately, there is no __execption_info var_decl
inside the _M_refcopy block tree, and thus we still have no origin_die, and
we hit the abort.  This is definitely fishy.  We have a decl that claims to
be inside a function, but the function claims to not know anything about the
decl.  I will have to investigate this further.

I can throw out a few wild guesses though, based on the fact that the problem
goes away when -freorder-blocks is turned off.
a) We generate a M_refcopy function that contains a __exception_info variable.
   We inline this into another function, generating an exception_info var
   with an abstract origin pointing back to us.  We then optimize and emit
   M_refcopy, and in the process of doing so, the block tree is modified such
   that the exception_info variable no longer exists.  We then later try to
   emit debug info for the inlinee, and we find a decl whose abstract origin
   no longer exists.  This problem does not exist with the RTL inliner, because
   we make a copy of the inline function before optimizing and emitting it,
   and hence all abstract origin pointers back to us remain valid.
b) We generate a M_refcopy function that does not contain a __exception_info
   variable.  We inline this into another function that does contain an
   _exception_info variable in other blocks.  We then optimize and emit the
   inlinee, and in the process of doing so we modify the block tree in such
   a way that we now have an exception_info variable inside the inlined
   M_refcopy function.  We we try to look for it inside the M_refcopy function
   we can't find it, and we end up aborting.

'b' seems pretty unlikely, as that would require that a DECL_CONTEXT field
get clobbered, and I don't think that -freorder-blocks can do that.  'a' seems
plausible though.

By the way, -freorder-blocks is known to have at least one other seriously
bad interaction with dwarf2out.c.  See 
	http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00434.html
This problem causes ia64-linux glibc build failures unless either -g or
-freorder-blocks is turned off.  This same problem has also been reported for
other linux systems, see the links at the bottom of the above message.

If the current problem is also a -freorder-blocks/dwarf2 interaction problem,
then perhaps -freorder-blocks shouldn't be on by default.

Jim