GCC Bugzilla Bug 26881

I get an internal compiler error when compiling Mozilla's standalone
spidermonkey JavaScript engine on x86, either with Fedora Core 5's gcc 4.1.0 or
a gcc 4.1.0 built from the released source.  I did *not* see this error taking
similar steps on x86_64.

jscpucfg.c:374: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:14116

I'll attach preprocessed source; I haven't had a chance to minimize the
testcase.

I'm using:
$ /usr/local/gcc-4.1.0/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/usr/local/gcc-4.1.0
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0

Created an attachment (id=11132) [edit]
preprocessed source (jscpucfg.i)

To see the bug, save this attachment as jscpucfg.i, and:

# gcc -c -o jscpucfg.o -g jscpucfg.i

Reducing.

Reduced testcase that fails even on x86_64:
int main(int argc, char **argv)
{
 if (0)
 {
   static union{} u;
   typedef char tt;
   static tt c[8];
   return c[0] == 0x01 && c[1] == 0x02;
 }
}

(gdb) up
#1  0x082e8034 in dwarf2out_finish (filename=0xbfb6d1ca "t.c")
    at /space/rguenther/src/svn/summit/gcc/dwarf2out.c:14104
14104                 gcc_assert (context && TREE_CODE (context) ==
FUNCTION_DECL);
(gdb) print context
$1 = (tree) 0xb7d91138
(gdb) call debug_generic_expr(context)
BLOCK
  SUPERCONTEXT: BLOCK 0xb7d9116c
  VARS: unionunion 
{
} uD.1525 ttD.1526 cD.1527 

eh?  what's that?  cfun is also NULL.

(gdb) call debug_generic_expr(node->created_for)
union 
{
}

*** Bug 27058 has been marked as a duplicate of this bug. ***

Here is an another testcase:

void bar (void)
{
 if (0) {
      static enum {a} foo;
      switch (0)
        {
        default:
          return;
        }
    }
}


Fail compiling with -O0 -g on x86_64 with gcc 4.1.1

Honza, this is caused by your patch:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00661.html
In -fno-unit-at-a-time mode, we used to pass the local var to dwarf2out only
when the containing function has been registered with dwarf2out, but now we
call dwarf2out_global_decl on local variables first and only after that
dwarf2out_decl on the containing function.

Jakub,
adding a worklist and passing all variables to dwarf2out as last it quite easy
to do.  However could you enlighten me a bit why the particular order is
needed?
Honza

For static variables in function contexts dwarf2out in several places wants
to look up the parent context DIE.  Now when the variables are registered
with dwarf2out before the containing function, the parent context DIE doesn't
exist yet.

PalmSource bug #126750.

Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.

This bug prevents the current release of the Globus toolkit
(www.globus.org) from compiling.

*** Bug 28379 has been marked as a duplicate of this bug. ***

Created an attachment (id=12032) [edit]
Patch in testing

(In reply to comment #12)
> This bug prevents the current release of the Globus toolkit
> (www.globus.org) from compiling.

A semi-workaround for getting SpiderMonkey to build is to export the
BUILD_OPT=1 environment variable. This tells the SpiderMonkey makefile to turn
off debugging, which causes the error to disappear. The down-side is that the
library is then built to another directory, so you may have to change your
Makefiles to accommodate finding the .so file in another place. For example, on
my machine it is output to js/Linux_All_OPT.OBJ/.

(In reply to comment #14)
Any news on the patch?

*** Bug 28782 has been marked as a duplicate of this bug. ***

Subject: Re:  [4.1/4.2 Regression] internal compiler error in dwarf2out_finish

> (In reply to comment #14)
> Any news on the patch?

Sadly we are having just tip of the iceberg here.  The patch to deffer
output of debug symbols later sort of work, but I noticed there are
other PRs related to problem where optimized out static variable is
still referred to by debug info, so I attempted to move debug output
code to cgraph domain and failed to do so.  The problem is that we are
quite inconsistent in way we do handle the optimized out variables.  In
some cases we do emit debug output for them, in other we don't and
in another we ICE depending on case and forntend.

I guess I will back out and implement the deferring itself without
touching the whole issue for start.  THen we probably ought to teach
debug info output machinery to query cgraph about whether the particular
variable was output or not and output the location or optimized out info
and move the debug output to cgraph at last (for both local and external
stuff, so we will need new datastructure in cgraph holding all
declarations in program somehow, as this is for now maintained only by
frontends)

Honza

Subject: Bug 26881

Author: hubicka
Date: Thu Aug 24 13:30:45 2006
New Revision: 116374

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116374
Log:
        PR debug/26881
        * cgraph.c: Fix comments.
        (cgraph_varpool_mark_needed_node): Mark only variables not already
        output to file.
        * cgraphunit.c: Update comments; include gt-cgraphunit.h
        (cgraph_varpool_assembled_nodes_queue): New static variable.
        (cgraph_varpool_assemble_decl): Record output decls for debug out code.
        (cgraph_varpool_output_debug_info): New function.
        (cgraph_finalize_compilation_unit, cgraph_optimize): Call it.
        * Makefile.in: Add gt-cgraphunit.h
        * gcc.dg/debug/pr26881.c: New file.

Added:
    trunk/gcc/testsuite/gcc.dg/debug/pr26881.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/cgraph.c
    trunk/gcc/cgraphunit.c
    trunk/gcc/testsuite/ChangeLog

Jan, do you intend to apply this to 4.1?

Subject: Bug 26881

Author: rguenth
Date: Tue Oct 17 11:30:28 2006
New Revision: 117823

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117823
Log:
2006-10-17  Richard Guenther  <rguenther@suse.de>

        Backport from mainline:
        2006-05-11  Jan Hubicka  <jh@suse.cz>

        PR debug/26881
        * Makefile.in (gt-cgraphunit.h): Add.
        * cgraphunit.c: Include gt-cgraphunit.h.
        (local_static_output): New static vector.
        (cgraph_varpool_assemble_decl): Defer outputting debug info
        for local statics to...
        (cgraph_varpool_debug_local_statics): ... here.
        (cgraph_optimize): Use it.

        2006-05-12  Jakub Jelinek  <jakub@redhat.com>

        PR debug/26881
        * gcc.dg/debug/pr26881.c: New test.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/debug/pr26881.c
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/Makefile.in
    branches/gcc-4_1-branch/gcc/cgraphunit.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog

Fixed.

*** Bug 27036 has been marked as a duplicate of this bug. ***

I get this very same issue also on sparc-solaris 2.10 with the mentioned source
and gcc v 4.1.1. So I hope 4.1.2 will fix this there too, but I get it there
only with option -ggdb, in case this helps anyway. Alternatively I could try
that patch on 4.1.1 myself... (I compiled that one myself)

*** Bug 29650 has been marked as a duplicate of this bug. ***

It seemed too difficult and risky to me to resolve the numerous rejects of the
attached patch against the 4.1.1 release, so I checked out today via svn the
4.1 branch in current state (30.10.2006). After changing a mask in the gcc
directory Makefile created by configure (sed needed there ' instead of ", I
didn't check, if gsed would have sufficed, but this was with /usr/xpg4/bin/sed,
so it is SUS V3 conformant) I succeeded in compiling that one and it resolved
this issue for me indeed when using the option -ggdb --- and works also if not
using this option.

*** Bug 30671 has been marked as a duplicate of this bug. ***

*** Bug 30782 has been marked as a duplicate of this bug. ***

*** Bug 31065 has been marked as a duplicate of this bug. ***