[Bug lto/51650] New: [4.7 regression] ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[Bug lto/51650] New: [4.7 regression] ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

             Bug #: 51650
           Summary: [4.7 regression] ICE in dwarf2out_finish, at
                    dwarf2out.c:22501 while building libxul
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: markus@trippelsdorf.de


After applying the patch that fixes Bug 51635 I've hit new bug
while building Firefox's libxul.

 % cat test.ii
extern "C" typedef int PRUint32;
typedef PRUint32 nsresult;
class nsQueryFrame
{
};
extern "C" struct PLDHashEntryHdr
{
};

template < class > class nsPtrHashKey:PLDHashEntryHdr
{
};

class nsIFrame;
namespace mozilla
{
  struct FramePropertyDescriptor
  {
  };
  class FramePropertyTable
  {
  public:FramePropertyTable ():mLastFrame (), mLastEntry ()
    {
    }
    void *Get (nsIFrame *, FramePropertyDescriptor *, bool *);
    class Entry:nsPtrHashKey < nsIFrame >
    {
    };
    nsIFrame *mLastFrame;
    Entry *mLastEntry;
  };
  class FrameProperties
  {
  public:FrameProperties ():mTable (), mFrame ()
    {
    }
    void *Get (FramePropertyDescriptor * aProperty)
    {
      mTable->Get (0, aProperty, 0);
    }
    FramePropertyTable *mTable;
    nsIFrame *mFrame;
  };
}

extern "C" class nsIFrame:nsQueryFrame
{
public:typedef mozilla::FramePropertyDescriptor FramePropertyDescriptor;
  typedef mozilla::FrameProperties FrameProperties;
  FrameProperties Properties ()
  {
  }
  static FramePropertyDescriptor *EmbeddingLevelProperty ()
  {
    static FramePropertyDescriptor descriptor;

    return &descriptor;
  }
};
nsresult
nsCaretGetCaretFrameForNodeOffset ()
{
  nsIFrame *theFrame;

  theFrame->Properties ().Get (nsIFrame::EmbeddingLevelProperty ());
}

 % g++ -flto -g -w test.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code, lto
          Component|lto                         |debug
   Target Milestone|---                         |4.7.0
            Summary|[4.7 regression] ICE in     |[4.7 regression] LTO ICE in
                   |dwarf2out_finish, at        |dwarf2out_finish, at
                   |dwarf2out.c:22501 while     |dwarf2out.c:22501 while
                   |building libxul             |building libxul

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011-12-22
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 11:28:57 UTC ---
Mine.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 11:44:04 UTC ---
Reduced testcase:

struct T;
class C
{
public:
    typedef ::T T;
    static T *m ()
      {
        static T *d;
        return d;
      }
};
int
fn ()
{
  C::m ();
}
int main() {}

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 12:00:27 UTC ---
In non-LTO mode we create the DIE for 'C' (which we do not create at all
with -flto) via

#3  0x0000000000d54c57 in rest_of_type_compilation (type=0x7ffff5b8f3f0, 
    toplev=1) at /space/rguenther/src/svn/trunk/gcc/passes.c:238
238       debug_hooks->type_decl (TYPE_STUB_DECL (type), !toplev);

we do not do something equivalent for LTO (but LTO expects to have those
DIEs created lazily ...).  But dwarf2out isn't prepared to deal with
this situation it seems :/

I'm not sure we want to add corresponding debug_hooks calls to the LTO
machinery, but if, then one place to do that would be here:

Index: gcc/lto/lto.c
===================================================================
--- gcc/lto/lto.c       (revision 182617)
+++ gcc/lto/lto.c       (working copy)
@@ -881,6 +881,8 @@ uniquify_nodes (struct data_in *data_in,
        lto_register_var_decl_in_symtab (data_in, t);
       else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
        lto_register_function_decl_in_symtab (data_in, t);
+      else if (!flag_wpa && TREE_CODE (t) == TYPE_DECL)
+       debug_hooks->type_decl (t, DECL_FILE_SCOPE_P (t));
       else if (TYPE_P (t) && !TYPE_CANONICAL (t))
        TYPE_CANONICAL (t) = gimple_register_canonical_type (t);
     }

but I'm not sure we won't confuse dwarf2out.c with the order we are
calling type_decl () either (might be we start with T, and then the
one for its context C).  The above patch fixes the reduced testcase at
least.

Markus, can you give it a shot?

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #4 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 12:51:08 UTC ---
(In reply to comment #3)
> In non-LTO mode we create the DIE for 'C' (which we do not create at all
> with -flto) via
> 
> #3  0x0000000000d54c57 in rest_of_type_compilation (type=0x7ffff5b8f3f0, 
>     toplev=1) at /space/rguenther/src/svn/trunk/gcc/passes.c:238
> 238       debug_hooks->type_decl (TYPE_STUB_DECL (type), !toplev);
> 
> we do not do something equivalent for LTO (but LTO expects to have those
> DIEs created lazily ...).  But dwarf2out isn't prepared to deal with
> this situation it seems :/
> 
> I'm not sure we want to add corresponding debug_hooks calls to the LTO
> machinery, but if, then one place to do that would be here:
> 
> Index: gcc/lto/lto.c
> ===================================================================
> --- gcc/lto/lto.c       (revision 182617)
> +++ gcc/lto/lto.c       (working copy)
> @@ -881,6 +881,8 @@ uniquify_nodes (struct data_in *data_in,
>         lto_register_var_decl_in_symtab (data_in, t);
>        else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
>         lto_register_function_decl_in_symtab (data_in, t);
> +      else if (!flag_wpa && TREE_CODE (t) == TYPE_DECL)
> +       debug_hooks->type_decl (t, DECL_FILE_SCOPE_P (t));
>        else if (TYPE_P (t) && !TYPE_CANONICAL (t))
>         TYPE_CANONICAL (t) = gimple_register_canonical_type (t);
>      }
> 
> but I'm not sure we won't confuse dwarf2out.c with the order we are
> calling type_decl () either (might be we start with T, and then the
> one for its context C).  The above patch fixes the reduced testcase at
> least.
> 
> Markus, can you give it a shot?

libxul still fails to build with the same error message (but there is only
one instance of this ICE now instead of three before your patch). 
Reducing...

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 13:10:44 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Markus, can you give it a shot?
> 
> libxul still fails to build with the same error message (but there is only
> one instance of this ICE now instead of three before your patch). 
> Reducing...

Sorry that it's going slow ... I hope we can populate the testsuite with
some more decent -flto -g coverage.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #6 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 13:17:46 UTC ---
 % cat test.ii
typedef struct { } X;
void test ()
{
  typedef X **P;
  P g = 0;
}

% g++ test.ii -g -flto -flto-partition=none
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501

(Will try to reduce again without -flto-partition=none)

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #7 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 13:26:26 UTC ---
(In reply to comment #6)
>  % cat test.ii
> typedef struct { } X;
> void test ()
> {
>   typedef X **P;
>   P g = 0;
> }
> 
> % g++ test.ii -g -flto -flto-partition=none
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> 
> (Will try to reduce again without -flto-partition=none)

Not necessary:
 % g++ -r- g -flto test.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 13:34:15 UTC ---
Oops, typo - it should be

      else if (!flag_wpa
               && TREE_CODE (t) == TYPE_DECL)
        debug_hooks->type_decl (t, !DECL_FILE_SCOPE_P (t));

(note the negation before the predicate).

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 15:28:32 UTC ---
Author: rguenth
Date: Thu Dec 22 15:28:24 2011
New Revision: 182625

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182625
Log:
2011-12-22  Richard Guenther  <rguenther@suse.de>

    PR lto/51650
    * lto.c (uniquify_nodes): Register TYPE_DECLs with the
    debuginfo machinery.

    * g++.dg/lto/pr51650-1_0.C: New testcase.
    * g++.dg/lto/pr51650-2_0.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/lto/pr51650-1_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr51650-2_0.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto/lto.c
    trunk/gcc/testsuite/ChangeLog

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-22 15:32:06 UTC ---
Fixed.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #11 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 15:33:55 UTC ---
I still hit the same spot when building Firefox.
delta is running...

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #12 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 18:45:24 UTC ---
 % cat pr51650.ii
class nsQueryFrame
{
};
struct PLDHashEntryHdr {
};

template < class > class nsPtrHashKey:PLDHashEntryHdr
{
};

class nsIFrame;
namespace mozilla
{
struct FramePropertyDescriptor {
};
class FramePropertyTable
{
public:
    FramePropertyTable ():mLastFrame (), mLastEntry () {
    }
    void *Get (nsIFrame *, FramePropertyDescriptor *, bool *);
    class Entry:nsPtrHashKey < nsIFrame >
    {
    };
    nsIFrame *mLastFrame;
    Entry *mLastEntry;
};
class FrameProperties
{
public:
    FrameProperties ():mTable (), mFrame () {
    }
    void *Get (FramePropertyDescriptor * aProperty) {
        mTable->Get (0, aProperty, 0);
    }
    FramePropertyTable *mTable;
    nsIFrame *mFrame;
};
}

class nsFrameList;
class nsIFrame:nsQueryFrame
{
public:
    typedef mozilla::FramePropertyDescriptor FramePropertyDescriptor;
    typedef mozilla::FrameProperties FrameProperties;
    virtual nsFrameList GetChildList ();
    FrameProperties Properties () {
    }
    static FramePropertyDescriptor *EmbeddingLevelProperty () {
        static FramePropertyDescriptor descriptor;
        return &descriptor;
    }
};

void
nsCaretGetCaretFrameForNodeOffset ()
{
    nsIFrame *theFrame;
    theFrame->Properties ().Get (nsIFrame::EmbeddingLevelProperty ());
}

 % g++ -r -nostdlib -g -flto -O1 pr51650.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #13 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 19:14:38 UTC ---
Reduced (it almost identical to the first testcase):

struct T;
class C
{
public:
    typedef ::T T;
    virtual void E();
    static T *m ()
      {
        static T *d;
        return d;
      }
};
int
fn ()
{
  C::m ();
}
int main() {}

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 09:17:41 UTC ---
Thanks ... :(

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 10:41:02 UTC ---
(In reply to comment #13)
> Reduced (it almost identical to the first testcase):
> 
> struct T;
> class C
> {
> public:
>     typedef ::T T;
>     virtual void E();
>     static T *m ()
>       {
>         static T *d;
>         return d;
>       }
> };
> int
> fn ()
> {
>   C::m ();
> }
> int main() {}

>From the C++ frontend the sequence is that we call debug_hooks->function_decl
for C::m from rest_of_handle_final which creates the type DIE for T.  With
LTO everything but main is optimized out, but we still emit debug info for
C::m::d via emit_debug_global_declarations () because we think C::m::d is
still live (for some reason ...).

That is, without LTO but with -fwhole-program we do not output
_ZZN1C1mEvE1d but with -flto we do (but we do not output C::m in either
case).  That seems to be a missed optimization (at least), probably
caused by applying the whole-program assumption late at WPA time:


Marking local functions: fn m


Marking externally visible functions: main


Marking externally visible variables:


Needed variables: d

why is d needed?

Reclaiming functions: fn m


cgraph pre whole_program_function_and_variable_visibility time:

main/2 @0x7ffff5a29900 (asm: main) availability:available analyzed reachable
body externally_visible prevailing_def finalized
  called by: 
  calls: 
  References: 
  Refering this function: 
fn/1 @0x7ffff5a297e0 (asm: _Z2fnv) availability:available analyzed reachable
body externally_visible prevailing_def_ironly finalized
  called by: 
  calls: m/0 (1.00 per call) 
  References: 
  Refering this function: 
m/0 @0x7ffff5a296c0 (asm: _ZN1C1mEv) availability:available analyzed reachable
body externally_visible finalized
  called by: fn/1 (1.00 per call) 
  calls: 
  References:  var:d (read)
  Refering this function: 

it seems that m/0 lacks a resolution, the resolution file has

1
t.o 3
195 67dffb6b12d80baf PREVAILING_DEF_IRONLY _Z2fnv
200 67dffb6b12d80baf PREVAILING_DEF main
202 67dffb6b12d80baf PREVAILING_DEF_IRONLY _ZZN1C1mEvE1d

hm.  And the function decl for m looks like

 <function_decl 0x7ffff5b60c00 m
    type <function_type 0x7ffff5b5f7e0
...
    addressable used nothrow public static weak autoinline QI defer-output
...

and it is DECL_COMDAT, so we do not output it to the LTO IL symtab and
thus do not get a resolution for it from the first loop.  In the
2nd loop we do not output it because the node isn't DECL_EXTERNAL either.

Why do we never output comdat unsharable functions and thus do not get
a resolution (which would be valid even if we end up unsharing them)?

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 11:13:20 UTC ---
We can fix the resolution with

Index: gcc/lto-symtab.c
===================================================================
--- gcc/lto-symtab.c    (revision 182652)
+++ gcc/lto-symtab.c    (working copy)
@@ -715,6 +715,14 @@ lto_symtab_merge_cgraph_nodes_1 (void **
 {
   lto_symtab_entry_t e, prevailing = (lto_symtab_entry_t) *slot;

+  if (prevailing->guessed)
+    {
+      if (prevailing->node)
+       prevailing->node->resolution = prevailing->resolution;
+      if (prevailing->vnode)
+       prevailing->vnode->resolution = prevailing->resolution;
+    }
+
   if (!prevailing->next)
     return 1;

but still the local static is marked needed because of

  if (node->finalized)
    varpool_mark_needed_node (node);

in input_varpool_node.  Not sure why we stream that flag at all?  Surely
whether to output sth is to be still decided?

I would say sth like

Index: gcc/lto-cgraph.c
===================================================================
--- gcc/lto-cgraph.c    (revision 182652)
+++ gcc/lto-cgraph.c    (working copy)
@@ -1080,6 +1080,8 @@ input_varpool_node (struct lto_file_decl
       DECL_EXTERNAL (node->decl) = 1;
       TREE_STATIC (node->decl) = 0;
     }
+  if (!flag_ltrans)
+    node->finalized = 0;
   if (node->finalized)
     varpool_mark_needed_node (node);
   if (non_null_aliasof)

is in order, or a similar

Index: gcc/lto-cgraph.c
===================================================================
--- gcc/lto-cgraph.c    (revision 182652)
+++ gcc/lto-cgraph.c    (working copy)
@@ -565,7 +565,7 @@ lto_output_varpool_node (struct lto_simp
   bp = bitpack_create (ob->main_stream);
   bp_pack_value (&bp, node->externally_visible, 1);
   bp_pack_value (&bp, node->force_output, 1);
-  bp_pack_value (&bp, node->finalized, 1);
+  bp_pack_value (&bp, in_lto_p && node->finalized, 1);
   bp_pack_value (&bp, node->alias, 1);
   bp_pack_value (&bp, node->alias_of != NULL, 1);
   gcc_assert (node->finalized || !node->analyzed);

Honza?

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #17 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 11:23:56 UTC ---
(In reply to comment #16)
> We can fix the resolution with
> 
> Index: gcc/lto-symtab.c
> ===================================================================
> --- gcc/lto-symtab.c    (revision 182652)
> +++ gcc/lto-symtab.c    (working copy)
> @@ -715,6 +715,14 @@ lto_symtab_merge_cgraph_nodes_1 (void **
>  {
>    lto_symtab_entry_t e, prevailing = (lto_symtab_entry_t) *slot;
> 
> +  if (prevailing->guessed)
> +    {
> +      if (prevailing->node)
> +       prevailing->node->resolution = prevailing->resolution;
> +      if (prevailing->vnode)
> +       prevailing->vnode->resolution = prevailing->resolution;
> +    }
> +
>    if (!prevailing->next)
>      return 1;
> 
> but still the local static is marked needed because of
> 
>   if (node->finalized)
>     varpool_mark_needed_node (node);
> 
> in input_varpool_node.  Not sure why we stream that flag at all?  Surely
> whether to output sth is to be still decided?
> 
> I would say sth like
> 
> Index: gcc/lto-cgraph.c
> ===================================================================
> --- gcc/lto-cgraph.c    (revision 182652)
> +++ gcc/lto-cgraph.c    (working copy)
> @@ -1080,6 +1080,8 @@ input_varpool_node (struct lto_file_decl
>        DECL_EXTERNAL (node->decl) = 1;
>        TREE_STATIC (node->decl) = 0;
>      }
> +  if (!flag_ltrans)
> +    node->finalized = 0;
>    if (node->finalized)
>      varpool_mark_needed_node (node);
>    if (non_null_aliasof)
> 
> is in order, or a similar
> 
> Index: gcc/lto-cgraph.c
> ===================================================================
> --- gcc/lto-cgraph.c    (revision 182652)
> +++ gcc/lto-cgraph.c    (working copy)
> @@ -565,7 +565,7 @@ lto_output_varpool_node (struct lto_simp
>    bp = bitpack_create (ob->main_stream);
>    bp_pack_value (&bp, node->externally_visible, 1);
>    bp_pack_value (&bp, node->force_output, 1);
> -  bp_pack_value (&bp, node->finalized, 1);
> +  bp_pack_value (&bp, in_lto_p && node->finalized, 1);
>    bp_pack_value (&bp, node->alias, 1);
>    bp_pack_value (&bp, node->alias_of != NULL, 1);
>    gcc_assert (node->finalized || !node->analyzed);
> 
> Honza?

See PR51663 for this issue.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 11:45:53 UTC ---
Even for

struct T;
struct C
{
    typedef ::T T;
    static T *m ()
      {
        static T *d __attribute__((used));
        return d;
      }
};
int
fn ()
{
  C::m ();
}
int main() {}

the C++ frontend works fine with -fwhole-program -g, outputting debug
information for C::m()::d (but in a way not accessible to gdb - huh):

16      int main() {}
(gdb) ptype 'C::m()::d' 
type = <data variable, no debug info>
(gdb) p 'C::m()::d' 
$1 = 0

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 11:51:41 UTC ---
A workaround for ICEs of this form is

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c     (revision 182652)
+++ gcc/dwarf2out.c     (working copy)
@@ -22496,15 +22496,23 @@ dwarf2out_finish (const char *filename)
              else if (TYPE_P (node->created_for))
                context = TYPE_CONTEXT (node->created_for);

-             gcc_assert (context
-                         && (TREE_CODE (context) == FUNCTION_DECL
-                             || TREE_CODE (context) == NAMESPACE_DECL));
+             if (!(context
+                   && (TREE_CODE (context) == FUNCTION_DECL
+                       || TREE_CODE (context) == NAMESPACE_DECL)))
+               {
+                 if (!in_lto_p)
+                   gcc_unreachable ();

-             origin = lookup_decl_die (context);
-             if (origin)
-               add_child_die (origin, die);
+                 add_child_die (comp_unit_die (), die);
+               }
              else
-               add_child_die (comp_unit_die (), die);
+               {
+                 origin = lookup_decl_die (context);
+                 if (origin)
+                   add_child_die (origin, die);
+                 else
+                   add_child_die (comp_unit_die (), die);
+               }
            }
        }
     }

just in case you want to look further ;)

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #20 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-23 13:56:55 UTC ---
(In reply to comment #19)
> A workaround for ICEs of this form is
> 
> Index: gcc/dwarf2out.c
> ===================================================================
> --- gcc/dwarf2out.c     (revision 182652)
> +++ gcc/dwarf2out.c     (working copy)
> @@ -22496,15 +22496,23 @@ dwarf2out_finish (const char *filename)
>               else if (TYPE_P (node->created_for))
>                 context = TYPE_CONTEXT (node->created_for);
> 
> -             gcc_assert (context
> -                         && (TREE_CODE (context) == FUNCTION_DECL
> -                             || TREE_CODE (context) == NAMESPACE_DECL));
> +             if (!(context
> +                   && (TREE_CODE (context) == FUNCTION_DECL
> +                       || TREE_CODE (context) == NAMESPACE_DECL)))
> +               {
> +                 if (!in_lto_p)
> +                   gcc_unreachable ();
> 
> -             origin = lookup_decl_die (context);
> -             if (origin)
> -               add_child_die (origin, die);
> +                 add_child_die (comp_unit_die (), die);
> +               }
>               else
> -               add_child_die (comp_unit_die (), die);
> +               {
> +                 origin = lookup_decl_die (context);
> +                 if (origin)
> +                   add_child_die (origin, die);
> +                 else
> +                   add_child_die (comp_unit_die (), die);
> +               }
>             }
>         }
>      }
> 
> just in case you want to look further ;)

Fortunately it seems that this bug was the last issue that needed to be fixed.
Firefox now builds fine with -lto and -g.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-02 15:52:45 UTC ---
(In reply to comment #20)
> 
> Fortunately it seems that this bug was the last issue that needed to be fixed.
> Firefox now builds fine with -lto and -g.

Can you also check the following variant?

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c     (revision 182784)
+++ gcc/dwarf2out.c     (working copy)
@@ -22501,15 +22501,8 @@ dwarf2out_finish (const char *filename)
              else if (TYPE_P (node->created_for))
                context = TYPE_CONTEXT (node->created_for);

-             gcc_assert (context
-                         && (TREE_CODE (context) == FUNCTION_DECL
-                             || TREE_CODE (context) == NAMESPACE_DECL));
-
-             origin = lookup_decl_die (context);
-             if (origin)
-               add_child_die (origin, die);
-             else
-               add_child_die (comp_unit_die (), die);
+             origin = get_context_die (context);
+             add_child_die (origin, die);
            }
        }
     }

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #22 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-01-02 16:52:49 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > 
> > Fortunately it seems that this bug was the last issue that needed to be fixed.
> > Firefox now builds fine with -lto and -g.
> 
> Can you also check the following variant?

Yes. This one is also OK.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

--- Comment #23 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-03 11:30:32 UTC ---
Author: rguenth
Date: Tue Jan  3 11:30:27 2012
New Revision: 182835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182835
Log:
2012-01-03  Richard Guenther  <rguenther@suse.de>

    PR debug/51650
    * dwarf2out.c (dwarf2out_finish): Always create a DIE for
    the context of a limbo DIE when it does not already exist.

    * g++.dg/lto/pr51650-3_0.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/lto/pr51650-3_0.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c
    trunk/gcc/testsuite/ChangeLog

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #24 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-03 11:31:12 UTC ---
Fixed.  Yay.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu.org

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-04 01:13:06 UTC ---
*** Bug 51224 has been marked as a duplicate of this bug. ***