diff mbox

RFC: PR bootstrap/59199: [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile

Message ID CAFiYyc2mMXyvR0P4VRaevMM-yaUNuhHYkCS5W9u6iAOfBOxgoA@mail.gmail.com
State New
Headers show

Commit Message

Richard Biener Nov. 29, 2013, 2:33 p.m. UTC 
On Fri, Nov 29, 2013 at 1:47 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Fri, Nov 29, 2013 at 1:27 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Nov 29, 2013 at 2:26 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Thu, Nov 28, 2013 at 6:22 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>>> There is a bad interaction between inlined C++ member functions
>>>> and LTO + profiledbootstrap, which leads to
>>>>
>>>> LTO bootstrap to fail with bootstrap-profile:
>>>>
>>>> Existing SSA name for symbol marked for renaming: aloop_37
>>>> In member function \u2018__base_ctor \u2019:
>>>> lto1: internal compiler error: SSA corruption
>>>> 0xcd84eb update_ssa(unsigned int)
>>>>         /export/project/git/gcc-regression/gcc/gcc/tree-into-ssa.c:3246
>>>> 0xa5814c input_function
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto-streamer-in.c:1006
>>>> 0xa5814c lto_read_body
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto-streamer-in.c:1070
>>>> 0xa5814c lto_input_function_body(lto_file_decl_data*, cgraph_node*, char
>>>> const*)
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto-streamer-in.c:1112
>>>> 0x66d2bc cgraph_get_body(cgraph_node*)
>>>>         /export/project/git/gcc-regression/gcc/gcc/cgraph.c:2981
>>>> 0x99aa58 ipa_merge_profiles(cgraph_node*, cgraph_node*)
>>>>         /export/project/git/gcc-regression/gcc/gcc/ipa-utils.c:699
>>>> 0x595a86 lto_cgraph_replace_node
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto/lto-symtab.c:82
>>>> 0x596159 lto_symtab_merge_symbols_1
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto/lto-symtab.c:561
>>>> 0x596159 lto_symtab_merge_symbols()
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto/lto-symtab.c:589
>>>> 0x5850dd read_cgraph_and_symbols
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto/lto.c:2946
>>>> 0x5850dd lto_main()
>>>>         /export/project/git/gcc-regression/gcc/gcc/lto/lto.c:3255
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> Please include the complete backtrace with any bug report.
>>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>>>
>>>> There are only 2 files which don't inline all loop_iterator
>>>> member function and may be miscompiled:
>>>>
>>>> File: ipa-inline-analysis.o
>>>>
>>>> Symbol table '.symtab' contains 454 entries:
>>>>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>>>> ...
>>>>    262: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    5
>>>> loop_iterator::loop_iterator(loop**, unsigned int)
>>>> ...
>>>>    352: 0000000000000000    89 FUNC    WEAK   DEFAULT   27
>>>> loop_iterator::next()
>>>>    353: 0000000000000000   748 FUNC    WEAK   DEFAULT   30
>>>> loop_iterator::loop_iterator(loop**, unsigned int)
>>>>    354: 0000000000000000   748 FUNC    WEAK   DEFAULT   30
>>>> loop_iterator::loop_iterator(loop**, unsigned int)
>>>> ...
>>>>
>>>> File: tree-cfg.o
>>>>
>>>> Symbol table '.symtab' contains 783 entries:
>>>>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>>>> ...
>>>>    385: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    5
>>>> loop_iterator::loop_iterator(loop**, unsigned int)
>>>> ...
>>>>    536: 0000000000000000   748 FUNC    WEAK   DEFAULT   34
>>>> loop_iterator::loop_iterator(loop**, unsigned int)
>>>> ...
>>>>    538: 0000000000000000   748 FUNC    WEAK   DEFAULT   34
>>>> loop_iterator::loop_iterator(loop**, unsigned int)
>>>> ...
>>>>
>>>> When either loop_iterator::next or loop_iterator::loop_iterator
>>>> inlined, bootstrap fails with the similar error.  This patch
>>>> works around the problem by not inlining those 2 functions.
>>>> On Nehalem machine using "make -j8", without the patch, I got
>>>>
>>>> 17836.13user 638.12system 55:49.72elapsed
>>>>
>>>> for bootstrap and
>>>>
>>>> 32362.67user 4313.11system 1:29:59elapsed
>>>>
>>>> for running testsuite.  With the patch, I got
>>>>
>>>> 7900.41user 640.39system 55:03.14elapsed
>>
>> It should be
>>
>> 17900.41user 640.39system 55:03.14elapsed
>>
>>>> for bootstrap and
>>>>
>>>> 31891.96user 4251.23system 1:31:41elapse
>>>>
>>>> for running testsuite.  There is very little performance
>>>> difference and the binaries are also a little bit smaller:
>>>>
>>>> 16787252          34920 1098648 17920820        1117334 build-x86_64-linux/gcc/cc1
>>>> 16809748          34920 1098648 17943316        111cb14 build-x86_64-linux.old/gcc/cc1
>>>> 19188340          35008 1126552 20349900        13683cc build-x86_64-linux/gcc/cc1objplus
>>>> 18865150          35008 1121848 20022006        13182f6 build-x86_64-linux/gcc/cc1plus
>>>> 19210836          35008 1126552 20372396        136dbac build-x86_64-linux.old/gcc/cc1objplus
>>>> 18887646          35008 1121848 20044502        131dad6 build-x86_64-linux.old/gcc/cc1plus
>>>> 17274027          44056 1104024 18422107        119195b build-x86_64-linux/gcc/f951
>>>> 17296523          44056 1104024 18444603        119713b build-x86_64-linux.old/gcc/f951
>>>> 17354837          51424 1105752 18512013        11a788d build-x86_64-linux/gcc/go1
>>>> 17377333          51424 1105752 18534509        11ad06d build-x86_64-linux.old/gcc/go1
>>>> 20815529          43928 6289304 27148761        19e41d9 build-x86_64-linux/gcc/gnat1
>>>> 20838025          43928 6289304 27171257        19e99b9 build-x86_64-linux.old/gcc/gnat1
>>>> 15944305          35688 1095064 17075057        1048b71 build-x86_64-linux/gcc/jc1
>>>> 15966801          35688 1095064 17097553        104e351 build-x86_64-linux.old/gcc/jc1
>>>>
>>>> Should this patch be applied to restore LTO bootstrap with
>>>> bootstrap-profile?
>>>
>>> I'd rather fix the bug than moving those functions out-of-line.  Is it enough
>>> to move the constructor and destructor out-of-line?
>>
>> No, it is independent of destructor.  We need to move both constructor
>> and loop_iterator::next out of line.
>
> Hm.  The ICE is weird - I'm trying to reproduce now.  I wonder whether
> we can and should move update_ssa before execute_all_ipa_stmt_fixups
> though.  Or add two - likely the latter does something wrong.
>
> So disabling IPA-CP will likely fix this as well.

!?  This happens during WPA stage.  Since when are we streaming
in function bodies there??

#6  0x00000000009b8089 in ipa_merge_profiles (
    dst=dst@entry=<cgraph_node* 0x7fffe8d343d8 "__base_ctor ">,
    src=src@entry=<cgraph_node* 0x7fffe8d55520 "__base_ctor ">)
    at /space/rguenther/tramp3d/trunk/gcc/ipa-utils.c:702
702       cgraph_get_body (src);

soo ...

we mark the symbol for renaming here:

  /* Process the statements.  */
  for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
    {
      gimple stmt;

      FOR_EACH_SSA_USE_OPERAND (use_p, stmt, i, SSA_OP_USE)
        {
          tree use = USE_FROM_PTR (use_p);
          if (!DECL_P (use))
            continue;
          mark_for_renaming (use);

on

(gdb) call debug_gimple_stmt (si.ptr)
# DEBUG ptr => &aloop

where obviously 'aloop' is not an SSA use operand.

(gdb) p verify_ssa_operands (si.ptr)
$13 = false

so the stmt is not up-to-date.  Ok, so the issue is that aloop is
not addressable.  I think this is a more general issue then and
nothing re-calls update_stmt on this DEBUG stmt without LTO.

We can't have

# DEBUG ptr => &aloop

when we have rewritten aloop into SSA form.

I'm thinking about how to fix it (and will try to create a testcase
without LTO).  Now for weekend ...

I think update_address_taken needs to also consider the
address-taken version.  Try



Richard.

> Richard.
>
>>
>> --
>> H.J.
diff mbox

Patch

Index: gcc/tree-ssa.c
===================================================================
--- gcc/tree-ssa.c      (revision 205520)
+++ gcc/tree-ssa.c      (working copy)
@@ -1329,6 +1336,10 @@  non_rewritable_mem_ref_base (tree ref)
   if (DECL_P (ref))
     return NULL_TREE;

+  /* For DEBUG_STMTs we have to look through ADDR_EXPRs.  */
+  if (TREE_CODE (ref) == ADDR_EXPR)
+    ref = TREE_OPERAND (ref, 0);
+
   while (handled_component_p (base))
     base = TREE_OPERAND (base, 0);