Test distilled from -gdwarf-2 -O3 bootstrap failure

[Alexandre Oliva]

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

> I'm going to try and debug this problem, so this is just a heads up.

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20020224-1.c
Type: text/x-c
Size: 686 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020224/6b4b16f1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwarf2-inlined-full.patch
Type: text/x-patch
Size: 556 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020224/6b4b16f1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwarf2-inlined-decls.patch
Type: text/x-patch
Size: 590 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020224/6b4b16f1/attachment-0002.bin>
-------------- next part --------------

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer