gcc 3, glibc 2.2, and DWARF2 failure

[Jim Wilson <wilson at cygnus dot com>]

Trying to compile glibc 2.2 with gcc3 for any target using DWARF2 debug info
will fail when you get to the printf_fp.c file.

printf_fp.c: In function `__printf_fp':
printf_fp.c:1144: Internal compiler error in gen_subprogram_die, at dwarf2out.c:10128

The problem here is a bad interaction between the -freorder-blocks optimization
and the dwarf2 debug output routines.  The problem occurs when you have a
nested function in a block that gets reordered.  reorder_blocks tries to make
the debug info sensible, but we end up with output that claims that the same
nested function has been defined two or more times, and the dwarf2 code doesn't
like that.  The exact same problem can be reproduced with loop unrolling, and
it is also much easier to write a testcase to reproduce the problem this way.

This example hits the gen_subprogram_die abort when compiled with -O
-funroll-loops -gdwarf-2.

sub ()
{
  int i;

  for (i = 0; i < 10; i++)
    {
      int nested () { return 0; }
    }
}

The same problem also exists for local variables, but we have a hack to
make it work.  It isn't clear if the hack will work for nested functions.
The real fix for this probably means changing the representation of symbol
table info for duplicated blocks of code.  That is probably not a simple fix.
>From gen_variable_die in dwarf2out.c:
  /* Loop unrolling can create multiple blocks that refer to the same
     static variable, so we must test for the DW_AT_declaration flag.  */
  /* ??? Loop unrolling/reorder_blocks should perhaps be rewritten to
     copy decls and set the DECL_ABSTRACT flag on them instead of
     sharing them.  */

This problem was reported to me in the context of ia64-linux, but scanning
the mailing lists, I also see that it has been reported against sh-linux and
alpha-linux.  Both messages contain testcases.
http://gcc.gnu.org/ml/gcc-patches/2000-10/msg01031.html
http://gcc.gnu.org/ml/gcc-bugs/2001-02/msg00655.html

I have more than enough IA-64 specific problems to work on, so I don't expect
to look into this any further anytime soon.  For now, we can work around the
problem by using -fno-reorder-blocks.

Jim