[Bug lto/63546] New: ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[Bug lto/63546] New: ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

            Bug ID: 63546
           Summary: ICE: Segmentation fault in lto_get_decl_name_mapping
                    on ppc64
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org

trippels@gcc1-power7 ~ % cat timezone.ii
class UnicodeString
{
public:
  void m_fn1 ();
} a;
void
fn1 ()
{
  static int b = 0;
  a.m_fn1 ();
}

trippels@gcc1-power7 ~ % /home/trippels/gcc_test/usr/local/bin/c++ -flto
-fdata-sections -g -O2 -r -nostdlib timezone.ii
lto1: internal compiler error: Segmentation fault
0x1063d46b crash_signal
        ../../gcc/gcc/toplev.c:340
0x104ed8c4 lto_get_decl_name_mapping(lto_file_decl_data*, char const*)
        ../../gcc/gcc/lto-section-in.c:340
0x1098f447 varpool_node::get_constructor()
        ../../gcc/gcc/varpool.c:280
0x1098f447 varpool_node::get_constructor()
        ../../gcc/gcc/varpool.c:264
0x10981c4f get_variable_section(tree_node*, bool)
        ../../gcc/gcc/varasm.c:1121
0x10983ae3 get_block_for_decl
        ../../gcc/gcc/varasm.c:1194
0x1098663b make_decl_rtl(tree_node*)
        ../../gcc/gcc/varasm.c:1419
0x10989f43 make_decl_rtl_for_debug(tree_node*)
        ../../gcc/gcc/varasm.c:1467
0x102523f7 rtl_for_decl_location
        ../../gcc/gcc/dwarf2out.c:15760
0x102871e7 loc_list_from_tree
        ../../gcc/gcc/dwarf2out.c:14391
0x1028dc13 add_location_or_const_value_attribute
        ../../gcc/gcc/dwarf2out.c:15892
0x1028dc13 add_location_or_const_value_attribute
        ../../gcc/gcc/dwarf2out.c:15836
0x10297707 dwarf2out_finish
        ../../gcc/gcc/dwarf2out.c:24243
Please submit a full bug report,
with preprocessed source if appropriate.
(gdb) up
#3  0x0000000010981c50 in get_variable_section (decl=0x3fffaf7003f0,
prefer_noswitch_p=<optimized out>) at ../../gcc/gcc/varasm.c:1121
1121    ../../gcc/gcc/varasm.c: No such file or directory.
(gdb) p debug_tree(decl)
 <var_decl 0x3fffaf7003f0 b
    type <integer_type 0x3fffaf6b07e0 int asm_written public SI
        size <integer_cst 0x3fffaf681380 constant 32>
        unit size <integer_cst 0x3fffaf681398 constant 4>
        align 32 symtab 16383 alias set -1 canonical type 0x3fffaf6b07e0
precision 32 min <integer_cst 0x3fffaf681338 -2147483648> max <integer_cst
0x3fffaf681350 2147483647>
        pointer_to_this <pointer_type 0x3fffaf6b1848>>
    static SI file timezone.ii line 9 col 14 size <integer_cst 0x3fffaf681380
32> unit size <integer_cst 0x3fffaf681398 4>
    align 32 context <function_decl 0x3fffaf843018 fn1> initial <error_mark
0x3fffaf681128>>
$1 = void

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
This may be too late to get at lto_file_decl_datas?

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> ---
> This may be too late to get at lto_file_decl_datas?
I think the problem is dwarf2out for whatever reason referring to a symbol that
was optimized out...
It does not make sense to try to figure out section of b when b is not going to
be output.

Honza

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-16
                 CC|                            |ccoutant at google dot com,
                   |                            |jakub at redhat dot com,
                   |                            |jason at redhat dot com
     Ever confirmed|0                           |1

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, the problem seems to be that dwarf2out tries to produce RTL for a variable
that is optimized out.  This happens here:

  /* Try harder to get a rtl.  If this symbol ends up not being emitted
     in the current CU, resolve_addr will remove the expression referencing
     it.  */
  if (rtl == NULL_RTX
      && TREE_CODE (decl) == VAR_DECL
      && !DECL_EXTERNAL (decl)
      && TREE_STATIC (decl)
      && DECL_NAME (decl)
      && !DECL_HARD_REGISTER (decl)
      && DECL_MODE (decl) != VOIDmode)
    {
      rtl = make_decl_rtl_for_debug (decl);
      if (!MEM_P (rtl)
          || GET_CODE (XEXP (rtl, 0)) != SYMBOL_REF
          || SYMBOL_REF_DECL (XEXP (rtl, 0)) != decl)
        rtl = NULL_RTX;
    }

producing RTL brings the function in, because it wants to work out its section
that breaks. I do not think dwarf2out really needs RTL for variable that was
never output.

Shall we kludge around and make make_decl_rtl-for_debug to not ICE but return
sort of random RTL or shall we just prevent this path with reference_to_unused
check?

For Martin and Trevor, I think safe workaround is to just comment out this
path.

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #3)
> OK, the problem seems to be that dwarf2out tries to produce RTL for a
> variable that is optimized out.  This happens here:
> 
>   /* Try harder to get a rtl.  If this symbol ends up not being emitted
>      in the current CU, resolve_addr will remove the expression referencing
>      it.  */
>   if (rtl == NULL_RTX
>       && TREE_CODE (decl) == VAR_DECL
>       && !DECL_EXTERNAL (decl)
>       && TREE_STATIC (decl)
>       && DECL_NAME (decl)
>       && !DECL_HARD_REGISTER (decl)
>       && DECL_MODE (decl) != VOIDmode)
>     {
>       rtl = make_decl_rtl_for_debug (decl);
>       if (!MEM_P (rtl)
>           || GET_CODE (XEXP (rtl, 0)) != SYMBOL_REF
>           || SYMBOL_REF_DECL (XEXP (rtl, 0)) != decl)
>         rtl = NULL_RTX;
>     }
> 
> producing RTL brings the function in, because it wants to work out its
> section that breaks. I do not think dwarf2out really needs RTL for variable
> that was never output.
> 
> Shall we kludge around and make make_decl_rtl-for_debug to not ICE but
> return sort of random RTL or shall we just prevent this path with
> reference_to_unused check?
> 
> For Martin and Trevor, I think safe workaround is to just comment out this
> path.

Commenting that out will severely decrease debug info quality.
Yes, dwarf2out really needs a RTL for those, and some that will not affect
-fcompare-debug, with the right (mangled?) name of the var and various other
attributes on the MEM.

Re: [Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[Jan Hubicka]

> 
> Commenting that out will severely decrease debug info quality.

It was meant as a workaround for PPC Firefox builds ;)

> Yes, dwarf2out really needs a RTL for those, and some that will not affect
> -fcompare-debug, with the right (mangled?) name of the var and various other
> attributes on the MEM.

Why are those needed for variables that was fully optimized out?  Mangled name
is acccessible via DECL_ASSEMBLER_NAME, so it may be prettier if dwarf2out
took it directly from DECL rather than going to RTL.

I suppose one can bypass the whole ancros machinery for those and avoid the
ICE. Produced RTL however won't be useful for any real work on it.

Honza

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> 
> Commenting that out will severely decrease debug info quality.

It was meant as a workaround for PPC Firefox builds ;)

> Yes, dwarf2out really needs a RTL for those, and some that will not affect
> -fcompare-debug, with the right (mangled?) name of the var and various other
> attributes on the MEM.

Why are those needed for variables that was fully optimized out?  Mangled name
is acccessible via DECL_ASSEMBLER_NAME, so it may be prettier if dwarf2out
took it directly from DECL rather than going to RTL.

I suppose one can bypass the whole ancros machinery for those and avoid the
ICE. Produced RTL however won't be useful for any real work on it.

Honza

Re: [Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[Jan Hubicka]

Here we die because we do not have variable constructor in LTO stream because
the variable was optimized out at compile time already.  Do we still need to
build RTL here?  We can easily check for optimized out vars...

But if we need a placeholder RTL, I suppose most practical variant would be
to avoid get_variable_section from ICEing for those optimized out vars and
just assume something (it is all about decision whether the var will be in 
rodata/rodata.rel or rodata.rel.local - definitely not relevant for dwarf2out)

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> ---
Here we die because we do not have variable constructor in LTO stream because
the variable was optimized out at compile time already.  Do we still need to
build RTL here?  We can easily check for optimized out vars...

But if we need a placeholder RTL, I suppose most practical variant would be
to avoid get_variable_section from ICEing for those optimized out vars and
just assume something (it is all about decision whether the var will be in 
rodata/rodata.rel or rodata.rel.local - definitely not relevant for dwarf2out)

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
Hi,
this patch should avoid production of RTL only for those vars that we know are
never used by real code.
Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 216317)
+++ dwarf2out.c (working copy)
@@ -15755,7 +15755,9 @@ rtl_for_decl_location (tree decl)
       && TREE_STATIC (decl)
       && DECL_NAME (decl)
       && !DECL_HARD_REGISTER (decl)
-      && DECL_MODE (decl) != VOIDmode)
+      && DECL_MODE (decl) != VOIDmode
+      && (symtab->state <= CONSTRUCTION
+         || varpool_node::get (decl)))
     {
       rtl = make_decl_rtl_for_debug (decl);
       if (!MEM_P (rtl)

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

--- Comment #9 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Adjusting importance because this is an ice-on-valid-code issue
on a primary platform.

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #10 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Seems to be fixed. Closing.