On Feb 24, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> Ok, I've figured out what's going on.  In the first round of expanding
> C bodies, f3() is deemed too big to be tree-inlined, so generation of
> RTL is not deferred for it, but generation of assembly is.  f4() is
> compiled to RTL and then assembly is generated for it, because it's
> referenced (by itself :-(, so f3() has to be emitted out-of-line
> because it couldn't be inlined.

> In the second round(), we generate RTL for f1() and f2(), but they are
> never emitted because they are inlined.  After generating assembly for
> f3(), however, we get in trouble because:

> - the inlined block from f1() contains the statement expression passed
>   as an argument from f2

> - the block copied from f1() was marked as ABSTRACT when we started
>   generating debugging info for the inlined f2:
>   dwarf2out_abstract_function() set the abstract flag in all blocks
>   within f2, irregardless of whether they came from other functions.


> I tried to skip blocks from f1(), but then we'd try to expand the
> initializer of its argument and lose.  It appears to me that we should
> be emitting debugging info for f1() just like for f2(), but the test
> for the block abstractness prevents that: blocks of inlined functions
> into inlined functions will always be marked as abstract.

> I'm now testing two different patches for the problem.  The first
> removes the test for abstractness of the block; the second simply
> arranges for us to generate declarations of the block.  The latter is
> enough to prevent the crash, and it seems reasonable under the
> principle that, if we don't generate debugging info for the whole
> block, we must at least generate it for the initializers of the
> parameters, as we'd have done had we not chosen to generate debugging
> info for the function.

> However, it appears to me that the former should be the right
> approach, since I don't see why handling f1 should be any different
> from f2.  We might emit more debugging info than necessary, though
> (but I'm not really sure about it).  Anyhow, it actually fails to
> bootstrap, as some labels referenced in the debugging info don't
> make it to the output.  So I'm leaning towards the second patch, but
> if others agree the former would be better, I'll dig deeper :-)

> For reference, here's the testcase I'm going to install in
> gcc.dg/debug (thanks Jakub!) as soon as a patch for the bug is
> approved, and the two candidate patches I'm testing (the first one
> actually fails to bootstrap, while the second is doing well, but I
> have doubts as to the correctness of the generated info).  ChangeLog
> entries missing because this is not a patch submission, just a RFC.
> So...  any comments?

Here's another alternative I'm trying right now.  It appears to be the
better than both I posted earlier, and it has just completed bootstrap
on athlon-pc-linux-gnu with BOOT_CFLAGS='-O3 -g'.  Ok to install if no
regressions are introduced in the testsuite?