This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/54728] [4.8 regression] ICE in input_gimple_stmt, at gimple-streamer-in.c:254


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

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

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-07 11:24:52 UTC ---
fn->decl is 0x7ffff6929300 which is _not_ the prevailing one!  DECL_CONTEXT
of the label points to the prevailing one instead.

I wonder why we materialize a non-prevailing function ... Honza?

This is from

static void
materialize_cgraph (void)
{
...
  FOR_EACH_FUNCTION (node)
    {
      if (node->symbol.lto_file_data)
        {
          lto_materialize_function (node);
          lto_stats.num_input_cgraph_nodes++;
        }
    }

at mixed WPA/LTRANS stage (-flto-partition=none).

We arrive in lto_symtab_merge_cgraph_nodes_1 for both and have
!symtab_real_symbol_p (e) for the non-prevailing decl:

 <function_decl 0x7ffff6929300 _M_refdata
    type <method_type 0x7ffff691fb28
        type <pointer_type 0x7ffff691fbd0 type <integer_type 0x7ffff691fc78
char>
            unsigned DI
            size <integer_cst 0x7ffff67e2d20 constant 64>
            unit size <integer_cst 0x7ffff67e2d40 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff67fb2a0>
        QI
        size <integer_cst 0x7ffff67e2ee0 constant 8>
        unit size <integer_cst 0x7ffff67e2f00 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff691fd20 method
basetype <record_type 0x7ffff691fe70 _Rep>
        arg-types <tree_list 0x7ffff691aed8 value <pointer_type 0x7ffff691fdc8>
            chain <tree_list 0x7ffff67ed6b8 value <void_type 0x7ffff67f3bd0
void>>>
        pointer_to_this <pointer_type 0x7ffff6924b28>>
    addressable used nothrow public static external autoinline QI defer-output
file t2.ii line 3 col 31 align 16 context <record_type 0x7ffff691fe70 _Rep>
    arguments <parm_decl 0x7ffff6926400 this
        type <pointer_type 0x7ffff6924150 type <record_type 0x7ffff691fe70
_Rep>
            readonly unsigned DI size <integer_cst 0x7ffff67e2d20 64> unit size
<integer_cst 0x7ffff67e2d40 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6924150>
        readonly unsigned DI file t2.ii line 3 col 50 size <integer_cst
0x7ffff67e2d20 64> unit size <integer_cst 0x7ffff67e2d40 8>
        align 64 context <function_decl 0x7ffff6920900 _M_refdata> arg-type
<pointer_type 0x7ffff6924150>>
    result <result_decl 0x7ffff6927618 D.2421 type <pointer_type
0x7ffff691fbd0>
        unsigned ignored DI file t2.ii line 3 col 31 size <integer_cst
0x7ffff67e2d20 64> unit size <integer_cst 0x7ffff67e2d40 8>
        align 64 context <function_decl 0x7ffff6920900 _M_refdata>>>

for which then the merging keeps the cgraph node around ...

The node is analyzed (it has a body!) but it's DECL_EXTERNAL, it doesn't
have callers and is not refered to.

So - is the above decl broken (public static external - huh), or should
lto_symtab_merge_cgraph_nodes_1 simply drop !symtab_real_symbol_p nodes
that have a body?

Should the above body materialization use

  FOR_EACH_FUNCTION (node)
    {
      if (symtab_real_symbol_p (&node->symbol))
        {
          lto_materialize_function (node);
          lto_stats.num_input_cgraph_nodes++;
        }
    }

instead?

Honza, please have a look here.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]