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.

Reply via email to