[Bug lto/59469] New: LLVM build failure with gcc LTO

[Bug lto/59469] New: LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

            Bug ID: 59469
           Summary: LLVM build failure with gcc LTO
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: octoploid at yandex dot com

Building LLVM with LTO fails:
...
lib/libLLVMAsmParser.so: error: undefined reference to
'llvm::SymbolTableListTraits<llvm::BasicBlock,llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>,
llvm::ilist_iterator<llvm::BasicBlock>)'

This only happens with "-O3 -flto":

markus@x4 llvm_build % g++ -flto-partition=none -flto -fPIC -shared -fno-rtti
-O3 BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep
"llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock"

markus@x4 llvm_build % g++ -flto-partition=none -flto -fPIC -shared -fno-rtti
-O2 BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep
"llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock"
000000000001b770 t llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)

markus@x4 llvm_build % g++ -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep
"llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock"
000000000006a6e0 W llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)
markus@x4 llvm_build %   

I will try to reduce this further.

[Bug lto/59469] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #1 from Markus Trippelsdorf <octoploid at yandex dot com> ---
Created attachment 31417
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31417&action=edit
testcase

[Bug lto/59469] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #2 from Markus Trippelsdorf <octoploid at yandex dot com> ---
markus@x4 llvm_build % cat BasicBlock.ii
struct A {};
namespace llvm {
struct B {};
template <typename> struct ilist_traits : B {};
template <typename> class ilist_iterator : A {
public:
  ilist_iterator(int) {}
  int operator!=(ilist_iterator &);
  void operator++();
};
template <typename NodeTy, typename Traits = ilist_traits<NodeTy> >
class C : Traits {
  C &transfer_L2;

public:
  A splice_where;
  void splice() { this->transferNodesFromList(transfer_L2, 0, 0); }
};
class Function;
template <typename ValueSubClass, typename ItemParentClass>
class SymbolTableListTraits : B {
public:
  ItemParentClass *getListOwner();
  void transferNodesFromList(ilist_traits<ValueSubClass> &p1,
                             ilist_iterator<ValueSubClass>,
                             ilist_iterator<ValueSubClass>);
};
class BasicBlock {
  Function *getParent();
  void moveBefore();
};
template <typename ValueSubClass, typename ItemParentClass>
void
SymbolTableListTraits<ValueSubClass, ItemParentClass>::transferNodesFromList(
    ilist_traits<ValueSubClass> &p1, ilist_iterator<ValueSubClass> p2,
    ilist_iterator<ValueSubClass> p3) {
  ItemParentClass a = *getListOwner() = *p1.getListOwner();
  int b = *ilist_traits<ValueSubClass>::getSymTab(0);
  for (; p2 != p3; ++p2)
    ;
}
template <>
struct ilist_traits<BasicBlock> : SymbolTableListTraits<BasicBlock, Function> {
  static int *getSymTab(Function *);
};
class Function : BasicBlock {
public:
  C<llvm::BasicBlock> &getBasicBlockList();
};
}

using namespace llvm;
BasicBlock c;
void BasicBlock::moveBefore() {
  c.getParent()->getBasicBlockList().splice();
  c.getParent()->getBasicBlockList().splice();
}

markus@x4 llvm_build % cat Function.ii
struct A {};
namespace llvm {
template <typename> struct ilist_traits;
class Function;
struct B {};
template <typename> class ilist_iterator : A {};
template <typename ValueSubClass, typename> class SymbolTableListTraits : B {
  void transferNodesFromList(ilist_traits<ValueSubClass> &p1,
                             ilist_iterator<ValueSubClass>,
                             ilist_iterator<ValueSubClass>);
};
class BasicBlock;
template <typename ValueSubClass, typename ItemParentClass>
void
SymbolTableListTraits<ValueSubClass, ItemParentClass>::transferNodesFromList(
    ilist_traits<ValueSubClass> &p1, ilist_iterator<ValueSubClass>,
    ilist_iterator<ValueSubClass>) {}
}

using namespace llvm;
template class ::SymbolTableListTraits<BasicBlock, Function>;

markus@x4 llvm_build % g++ -flto -O3 -fPIC -shared BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
markus@x4 llvm_build % g++ -flto -O2 -fPIC -shared BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
00000000000009e0 t llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)
markus@x4 llvm_build % g++ -O3 -fPIC -shared BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
0000000000000b50 W llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)
markus@x4 llvm_build % clang++ -flto -O3  -w -fPIC -shared BasicBlock.ii
Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
0000000000000b70 W llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)
markus@x4 llvm_build %

[Bug lto/59469] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #3 from Markus Trippelsdorf <octoploid at yandex dot com> ---
BTW it is interesting that gcc compiles the attached testcase faster
when using LTO.

 % time g++ -flto=4 -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii
52.48s user 0.59s system 168% cpu 31.545 total
 % time g++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii
46.94s user 0.30s system 99% cpu 47.258 total

(for comparison clang trunk (70% faster):
  % time clang++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii
15.48s user 0.14s system 99% cpu 15.628 total)

[Bug lto/59469] LLVM build failure with gcc LTO

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #3)
> BTW it is interesting that gcc compiles the attached testcase faster
> when using LTO.
> 
>  % time g++ -flto=4 -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
> Function.ii
> 52.48s user 0.59s system 168% cpu 31.545 total
>  % time g++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
> Function.ii
> 46.94s user 0.30s system 99% cpu 47.258 total
> 
> (for comparison clang trunk (70% faster):
>   % time clang++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
> Function.ii
> 15.48s user 0.14s system 99% cpu 15.628 total)

Is GCC configured with --enable-checking=release?  If not then you should not
compare to LLVM's compile time.

[Bug lto/59469] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #5 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Markus Trippelsdorf from comment #3)
> > BTW it is interesting that gcc compiles the attached testcase faster
> > when using LTO.
> > 
> >  % time g++ -flto=4 -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
> > Function.ii
> > 52.48s user 0.59s system 168% cpu 31.545 total
> >  % time g++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
> > Function.ii
> > 46.94s user 0.30s system 99% cpu 47.258 total
> > 
> > (for comparison clang trunk (70% faster):
> >   % time clang++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
> > Function.ii
> > 15.48s user 0.14s system 99% cpu 15.628 total)
> 
> Is GCC configured with --enable-checking=release?  If not then you should
> not compare to LLVM's compile time.

Yes. Sorry, I forgot to mention it: --enable-checking=release PGO/LTO build.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto
                 CC|                            |hubicka at gcc dot gnu.org
          Component|lto                         |ipa
   Target Milestone|---                         |4.9.0
            Summary|LLVM build failure with gcc |[4.8/4.9 Regression] LLVM
                   |LTO                         |build failure with gcc LTO

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
With -fno-fat-lto-objects we are also faster on SPEC build time and I think it
should be the case in general.  We produce considerably less code and most of
time is spent in the backend.  For super large projects with parallel makefiles
the time spent in serial WPA may overweight the benefits, but for GCC and
firefox I believe the only problem is that it builds multiple binaries from
same static libraries.  Here we end up optimizing the static libraries many
times, while in traditional build we optimize just once.

Let me see if I can reproduce the weak symbol. In these cases my life would be
a lot easier if you attached the resolution file and told me the unmangled name
of the symbol. But thanks a lot for the analysis and LTO testing! It is badly
needed.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #7 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Jan Hubicka from comment #6)
> With -fno-fat-lto-objects we are also faster on SPEC build time and I think
> it should be the case in general.  We produce considerably less code and
> most of time is spent in the backend.  For super large projects with
> parallel makefiles the time spent in serial WPA may overweight the benefits,
> but for GCC and firefox I believe the only problem is that it builds
> multiple binaries from same static libraries.  Here we end up optimizing the
> static libraries many times, while in traditional build we optimize just
> once.

Naive question: Why not use dynamic libraries in the case of gcc?

> Let me see if I can reproduce the weak symbol. In these cases my life would
> be a lot easier if you attached the resolution file and told me the
> unmangled name of the symbol. But thanks a lot for the analysis and LTO
> testing! It is badly needed.

sorry:

_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_

 % cat BasicBlock.res
2
BasicBlock.o 9
234 e1ebf4c224baf514 PREVAILING_DEF_IRONLY_EXP
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
239 e1ebf4c224baf514 PREVAILING_DEF_IRONLY_EXP
_ZN4llvm10BasicBlock10moveBeforeEv
290 e1ebf4c224baf514 PREVAILING_DEF_IRONLY_EXP c
247 e1ebf4c224baf514 UNDEF _ZN4llvm14ilist_iteratorINS_10BasicBlockEEneERS2_
252 e1ebf4c224baf514 UNDEF _ZN4llvm14ilist_iteratorINS_10BasicBlockEEppEv
257 e1ebf4c224baf514 UNDEF
_ZN4llvm12ilist_traitsINS_10BasicBlockEE9getSymTabEPNS_8FunctionE
262 e1ebf4c224baf514 UNDEF
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE12getListOwnerEv
283 e1ebf4c224baf514 UNDEF _ZN4llvm8Function17getBasicBlockListEv
288 e1ebf4c224baf514 UNDEF _ZN4llvm10BasicBlock9getParentEv
Function.o 1
214 bf4c643d7570440b PREEMPTED_IR
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, the unmangled name of symbol is:
000000000004c8c0 T
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_

and obviously for me it is T for -O2 and for -O3 it is optimized out.  Both
seems legitimate. Can you please re-check with current mainline?

I get:
 df live regs            :   7.74 (12%) usr   0.00 ( 0%) sys   7.72 (12%) wall 
     0 kB ( 0%) ggc
 df live&initialized regs:  11.02 (17%) usr   0.00 ( 0%) sys  10.91 (17%) wall 
     0 kB ( 0%) ggc
 CPROP                   :  20.03 (32%) usr   0.44 (65%) sys  20.51 (32%) wall 
  7968 kB ( 5%) ggc

(with checking on, but still seems something for steve, I do not think there is
particularly expensive checking in CPROP)

I am re-checking with 4.8

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
LTO-ing libbackend.a into every frontend binary theoretically results in better
code.  I did not see numbers on this.
Now I understand what you complain about. LTO build optimizes out the symbol or
makes it static, while non-LTO build produces weak.
I think this is correct: weak symbols should be always produced by the unit
that needs it unless they are keyed. This one does not seem to be.
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295
(transferNodesFromList) @0x7fd527d7ee18
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly_exp public weak comdat
comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
one_only
  next sharing asm name: 9004
  References:
  Referring:
  Read from file: BasicBlock.o
  First run: 0
  Function flags:
  Called by:
_ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE8transferENS_14ilist_iteratorIS1_EERS4_S6_S6_/3184
(0.90 per call) (can throw external)
  Calls: _ZN4llvm10BasicBlock9setParentEPNS_8FunctionE/2560 (1.36 per call)
(can throw external) _ZN4llvm16ValueSymbolTable13reinsertValueEPNS_5ValueE/4100
(2.24 per call) (can throw exte

So I think the problem really is libLLVMAsmParser.so requring this symbol while
not providing weak definition.  Can you look into resolution file and
-fdump-ipa-cgraph file how the symbol looks like while building the library?
It may also be error on llvm side declaring the symbol but not providing inline
definition within some source file of libASMParser. (I saw similar things in
Firefox)

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I also saw in past problems with GNU-ld and comdat symbols becoming static
while being comdat somewhere else.  Do you use gold or ld? Can you perhaps try
to use the other one and see if anything changes?

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #11 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Jan Hubicka from comment #8)
> OK, the unmangled name of symbol is:
> 000000000004c8c0 T
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
> 
> and obviously for me it is T for -O2 and for -O3 it is optimized out.  Both
> seems legitimate. Can you please re-check with current mainline?
> 
> I get:
>  df live regs            :   7.74 (12%) usr   0.00 ( 0%) sys   7.72 (12%)
> wall       0 kB ( 0%) ggc
>  df live&initialized regs:  11.02 (17%) usr   0.00 ( 0%) sys  10.91 (17%)
> wall       0 kB ( 0%) ggc
>  CPROP                   :  20.03 (32%) usr   0.44 (65%) sys  20.51 (32%)
> wall    7968 kB ( 5%) ggc
> 
> (with checking on, but still seems something for steve, I do not think there
> is particularly expensive checking in CPROP)
> 
> I am re-checking with 4.8

4.7 and 4.8 are also slow.
perf top shows:
 12.80%   cc1plus  cc1plus [.] compute_cprop_data()
  8.64%   cc1plus  cc1plus [.] df_worklist_dataflow(dataflow*, bitmap_head*,
int*, int)
  5.80%   cc1plus  cc1plus [.] bitmap_set_bit(bitmap_head*, int)
  4.61%   cc1plus  cc1plus [.] bitmap_ior_into(bitmap_head*, bitmap_head
const*)
...

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #12 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Jan Hubicka from comment #10)
> I also saw in past problems with GNU-ld and comdat symbols becoming static
> while being comdat somewhere else.  Do you use gold or ld? Can you perhaps
> try to use the other one and see if anything changes?

I use gold. But it doesn't matter in this case, because bfd behaves identical.

Thanks for your analysis. I just added a few __attribute__((used)) for 
now and this fixes the issue.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Markus Trippelsdorf from comment #12)
> (In reply to Jan Hubicka from comment #10)
> > I also saw in past problems with GNU-ld and comdat symbols becoming static
> > while being comdat somewhere else.  Do you use gold or ld? Can you perhaps
> > try to use the other one and see if anything changes?
> 
> I use gold. But it doesn't matter in this case, because bfd behaves
> identical.
> 

Can you try bfd linker, hjl/linux/release/2.24.51.0.2, from

https://sourceware.org/git/?p=binutils-gdb.git;a=summary

It has a modified LTO bfd linker.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #13)
> Can you try bfd linker, hjl/linux/release/2.24.51.0.2, from
> 
> https://sourceware.org/git/?p=binutils-gdb.git;a=summary
> 
> It has a modified LTO bfd linker.

You need to build LLVM from scratch with my bfd linker.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-15
     Ever confirmed|0                           |1

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We should analyze why we end up with missing symbol. __attribute__ ((used))
will prevent privatization of the symbol. Rather than that it would be better
to figure out what object file of the library actually need it and look at the
preprocessed source code if the inline version is there.

I just rebuilt without testing and indeed it seems that cprop and df seems to
degenerate here quite noticeably.

It is lookupIntrinsicID that consume a lot of time and its CFG is not small:

$4 = {x_entry_block_ptr = 0x7ffff65b22d8, x_exit_block_ptr = 0x7ffff65b2340,
x_basic_block_info = 0x7ffff48df000, x_n_basic_blocks = 13898, x_n_edges =
22158, 
  x_last_basic_block = 13898, last_label_uid = 8660, x_label_to_block_map =
0x0, x_profile_status = PROFILE_GUESSED, x_dom_computed = {DOM_NONE, DOM_NONE},
x_n_bbs_in_dom_tree = {0, 0}, 
  max_jumptable_ents = 34}

But it does not really explain why cprop should that that much of time.
It seems that the function is huge sequence of ifs compiling into:
<L3807>:
  _3982 = &MEM[(void *)_5 + 31B];
  _3983 = memcmp (_3982, "tore", 4);
  if (_3983 != 0)
    goto <bb 4208>;
  else
    goto <bb 5260>;
plus a lot of PHIs that probably makes cprop to work hard...
I wonder if we can't inline those stupid memcmps somehow.

Marking as NEW at least for the performance problem.  Still unsure if the
original problem is source bug or GCC bug.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #17 from Markus Trippelsdorf <octoploid at yandex dot com> ---
In the non-lto case one has:
lib/libLLVMAsmParser.so:
U
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
lib/libLLVMCore.so:
0000000000071e90 W
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8

Later they get linked together:
... -o bin/llvm-as lib/libLLVMAsmParser.so ... lib/libLLVMCore.so  ...

In the lto case the weak symbol in lib/libLLVMCore.so is optimized out
and the build fails. 

lib/libLLVMCore.so normally gets this weak symbol from BasicBlock.ii and
Function.ii, that I've attached above.

If I understand you correctly, you say that the undefined symbol
of lib/libLLVMAsmParser.so is a bug in LLVM.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[steven at gcc dot gnu.org]

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

--- Comment #18 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> OK, the unmangled name of symbol is:
> 000000000004c8c0 T
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
> 
> and obviously for me it is T for -O2 and for -O3 it is optimized out.  Both
> seems legitimate. Can you please re-check with current mainline?
> 
> I get:
>  df live regs            :   7.74 (12%) usr   0.00 ( 0%) sys   7.72 (12%)
> wall       0 kB ( 0%) ggc
>  df live&initialized regs:  11.02 (17%) usr   0.00 ( 0%) sys  10.91 (17%)
> wall       0 kB ( 0%) ggc
>  CPROP                   :  20.03 (32%) usr   0.44 (65%) sys  20.51 (32%)
> wall    7968 kB ( 5%) ggc
> 
> (with checking on, but still seems something for steve, I do not think there
> is particularly expensive checking in CPROP)
> 
> I am re-checking with 4.8

I can't reproduce this.
What platform is this? What is the command line?

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at ucw dot cz]

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

--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> ---
> I can't reproduce this.
> What platform is this? What is the command line?

I used x86-64 and you apparently need LTO to trigger it.  I used same
commandline
as in original report
g++ -flto-partition=none -flto -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii

You may produce object files and that will get you to dataflow earilier.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at ucw dot cz]

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

--- Comment #20 from Jan Hubicka <hubicka at ucw dot cz> ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> 
> --- Comment #17 from Markus Trippelsdorf <octoploid at yandex dot com> ---
> In the non-lto case one has:
> lib/libLLVMAsmParser.so:
> U
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_

I think this is a bug by itself, since the symbol seems to be nonkeyed comdat
and thus
every unit that use it should define it.

> If I understand you correctly, you say that the undefined symbol
> of lib/libLLVMAsmParser.so is a bug in LLVM.

I think it is eitehr bug in source (LLVM). Most probably becuase
libLLVMAsmParser simply omits inline definition in libLLVMAsmParser.so where it
should not or some sort of bug in C++ visibility logic.

For that we need to figure out how the symbol is defined and used in
lib/libLLVMAsmParser.so

Honza

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

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

--- Comment #21 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Jan Hubicka from comment #20)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> > 
> > --- Comment #17 from Markus Trippelsdorf <octoploid at yandex dot com> ---
> > In the non-lto case one has:
> > lib/libLLVMAsmParser.so:
> > U
> > _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
> 
> I think this is a bug by itself, since the symbol seems to be nonkeyed
> comdat and thus
> every unit that use it should define it.
> 
> > If I understand you correctly, you say that the undefined symbol
> > of lib/libLLVMAsmParser.so is a bug in LLVM.
> 
> I think it is eitehr bug in source (LLVM). Most probably becuase
> libLLVMAsmParser simply omits inline definition in libLLVMAsmParser.so where
> it
> should not or some sort of bug in C++ visibility logic.
> 
> For that we need to figure out how the symbol is defined and used in
> lib/libLLVMAsmParser.so

libLLVMAsmParser.so only uses the declaration:
http://llvm.org/docs/doxygen/html/SymbolTableListTraits_8h_source.html

And not the definition:
http://llvm.org/docs/doxygen/html/SymbolTableListTraitsImpl_8h_source.html

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
00010 // This file implements the stickier parts of the SymbolTableListTraits
class,
00011 // and is explicitly instantiated where needed to avoid defining all this
code
00012 // in a widely used header.

I would thus say that libLLVMAsmParser.s misses the explicit instantiation in
it?

Honza

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #15)
> We should analyze why we end up with missing symbol. __attribute__ ((used))
> will prevent privatization of the symbol. Rather than that it would be
> better to figure out what object file of the library actually need it and
> look at the preprocessed source code if the inline version is there.
> 
> I just rebuilt without testing and indeed it seems that cprop and df seems
> to degenerate here quite noticeably.
> 
> It is lookupIntrinsicID that consume a lot of time and its CFG is not small:
> 
> $4 = {x_entry_block_ptr = 0x7ffff65b22d8, x_exit_block_ptr = 0x7ffff65b2340,
> x_basic_block_info = 0x7ffff48df000, x_n_basic_blocks = 13898, x_n_edges =
> 22158, 
>   x_last_basic_block = 13898, last_label_uid = 8660, x_label_to_block_map =
> 0x0, x_profile_status = PROFILE_GUESSED, x_dom_computed = {DOM_NONE,
> DOM_NONE}, x_n_bbs_in_dom_tree = {0, 0}, 
>   max_jumptable_ents = 34}
> 
> But it does not really explain why cprop should that that much of time.
> It seems that the function is huge sequence of ifs compiling into:
> <L3807>:
>   _3982 = &MEM[(void *)_5 + 31B];
>   _3983 = memcmp (_3982, "tore", 4);
>   if (_3983 != 0)
>     goto <bb 4208>;
>   else
>     goto <bb 5260>;
> plus a lot of PHIs that probably makes cprop to work hard...
> I wonder if we can't inline those stupid memcmps somehow.
> 
> Marking as NEW at least for the performance problem.  Still unsure if the
> original problem is source bug or GCC bug.

See PR52171.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[rafael.espindola at gmail dot com]

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

Rafael Avila de Espindola <rafael.espindola at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rafael.espindola at gmail dot com

--- Comment #24 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> ---
(In reply to Jan Hubicka from comment #22)
> 00010 // This file implements the stickier parts of the
> SymbolTableListTraits class,
> 00011 // and is explicitly instantiated where needed to avoid defining all
> this code
> 00012 // in a widely used header.
> 
> I would thus say that libLLVMAsmParser.s misses the explicit instantiation
> in it?

It looks like the expected/correct result is for libLLVMAsmParser.so to have an
undefined reference that is satisfied by a definition in libLLVMCore.so. The
definition should come from an explicit template instantiation in Function.cpp.

Markus, do you see the definition in Function.o? What about libLLVMCore.so?

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

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

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

--- Comment #25 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Rafael Avila de Espindola from comment #24)
> (In reply to Jan Hubicka from comment #22)
> > 00010 // This file implements the stickier parts of the
> > SymbolTableListTraits class,
> > 00011 // and is explicitly instantiated where needed to avoid defining all
> > this code
> > 00012 // in a widely used header.
> > 
> > I would thus say that libLLVMAsmParser.s misses the explicit instantiation
> > in it?
> 
> It looks like the expected/correct result is for libLLVMAsmParser.so to have
> an undefined reference that is satisfied by a definition in libLLVMCore.so.
> The definition should come from an explicit template instantiation in
> Function.cpp.
> 
> Markus, do you see the definition in Function.o? What about libLLVMCore.so?

Yes, is see the weak symbol both in BasicBlock.o and Function.o.
However it gets optimized away when I link them with "-flto -O3" into
libLLVMCore.so (see comment 0).

Honza says it is an error to have the symbol undefined in libLLVMAsmParser.so.
(The undefined symbol comes from LLParser.cpp)

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #27 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 31789
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31789&action=edit
BasicBlock.ii reduced

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #28 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 31790
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31790&action=edit
Function.ii reduced

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #30 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #29)
> > 
> > That optimization seems invalid. There is a explicit template instantiation
> > definition, so it is valid for other dsos to have an undefined reference.
> 
> Can I see the cgraph dump of the unreduced source file containing the
> explicit
> instantiation?

It's in the first bziped attachment: Function.ii line 71217.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #31 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, the visibility is:
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295
(transferNodesFromList) @0x7fd527d7ee18
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly_exp public weak comdat 

if the function is explicitly instantiated and required to be exported from
module by ABI, it needs forced_by_abi flag. In that case it is an FE bug.
Can you point me to that instantiation? It is hard for me to parse the .ii file
:(

Honza

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #32 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #31)
> OK, the visibility is:
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295
> (transferNodesFromList) @0x7fd527d7ee18
>   Type: function definition analyzed
>   Visibility: externally_visible prevailing_def_ironly_exp public weak
> comdat 
> 
> if the function is explicitly instantiated and required to be exported from
> module by ABI, it needs forced_by_abi flag. In that case it is an FE bug.
> Can you point me to that instantiation? It is hard for me to parse the .ii
> file :(

As I wrote above: The instantiation is on line 71217.

[Bug c++/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com
          Component|ipa                         |c++

--- Comment #33 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, either the testcase is invalid since ODR forbids you to have function
inline in one unit and not inline in other, or C++ FE should call mark_used on
the explicitly instantiated comdat.  In any case, I am changing component to
C++.

Jason, any chance you can look on this?

[Bug c++/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #34 from Jason Merrill <jason at gcc dot gnu.org> ---
Created attachment 31949
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31949&action=edit
mark_needed patch

I don't see the function being declared 'inline' anywhere, so there's no ODR
violation.

I tried adding a mark_needed call to mark_decl_instantiated, as in this patch. 
But setting forced_by_abi on the cgraph node for the instantiation doesn't seem
to help; the LTO output still has a private symbol.

[Bug c++/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[jason at gcc dot gnu.org]

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

--- Comment #35 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Fri Jan 31 18:35:53 2014
New Revision: 207366

URL: http://gcc.gnu.org/viewcvs?rev=207366&root=gcc&view=rev
Log:
    PR c++/59469
    * pt.c (mark_decl_instantiated): Call mark_needed.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/pt.c

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |ipa

--- Comment #36 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #34)
> I tried adding a mark_needed call to mark_decl_instantiated, as in this
> patch.  But setting forced_by_abi on the cgraph node for the instantiation
> doesn't seem to help; the LTO output still has a private symbol.

With this patch (which I just checked in), the cgraph dump looks like

_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3692
(void llvm::SymbolTableListTraits<ValueSubClass,
ItemParentClass>::transferNodesFromList(llvm::ilist_traits<NodeTy>&,
llvm::ilist_iterator<NodeTy>, llvm::ilist_iterator<NodeTy>) [with ValueSubClass
= llvm::BasicBlock; ItemParentClass = llvm::Function]) @0x7f75f3a373d8
  Type: function definition analyzed
  Visibility: forced_by_abi public weak
comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
one_only

So I don't know why LTO is still turning it into a local symbol.

Changing component back to ipa.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #37 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
I think the error is that the symbol from the explicit template instantiation
in Function.ii (marked with forced_by_abi) gets merged with the symbol in the
same COMDAT group from BasicBlock.ii. (This symbol isn't marked with
forced_by_abi, but somehow has prevailing_def_ironly_exp)

Merging nodes for
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_.
Candidates:
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/9
(transferNodesFromList) @0x7f4d65008e18
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly_exp public weak comdat
comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromLi
stERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only
  next sharing asm name: 22
  References: 
  Referring: 
  Read from file: /tmp/ccx3oVJ3.o
  First run: 0
  Function flags:
  Called by: _ZN4llvm10BasicBlock10moveBeforeEv/1 (1.00 per call) (can throw
external) _ZN4llvm10BasicBlock10moveBeforeEv/1 (1.00 per call) (can throw
external) 
  Calls: _ZN4llvm14ilist_iteratorINS_10BasicBlockEEneERS2_/16 (11.11 per call)
(can throw external) _ZN4llvm14ilist_iteratorINS_10BasicBlockEEppEv/15 (10.11
per call) (can throw external)
_ZN4llvm12ilist_traitsINS_10BasicBlockEE9getSymTabEPNS_8FunctionE/14 (1.00 per
call) (can throw external)
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8Fu
nctionEE12getListOwnerEv/13 (1.00 per call) (can throw external)
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE12getListOwnerEv/13
(1.00 per call) (can throw 
external) 
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/22
(transferNodesFromList) @0x7f4d651888f8
  Type: function definition analyzed
  Visibility: forced_by_abi externally_visible preempted_ir public weak
comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS
_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only
  previous sharing asm name: 9
  References: 
  Referring: 
  Read from file: /tmp/ccZVoWfZ.o
  First run: 0
  Function flags:
  Called by: 
  Calls:

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #39 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Ha, good catch. Forced_by_abi is a flag that needs to be merged.  You do not
want to set force_output as your patch does, just forced_by_abi.  I will test
the patch.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #40 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Tue Feb  4 05:50:18 2014
New Revision: 207449

URL: http://gcc.gnu.org/viewcvs?rev=207449&root=gcc&view=rev
Log:

    PR ipa/59469
    * lto-symtab.c (lto_cgraph_replace_node, lto_varpool_replace_node):
    merge force_output and forced_by_abi flags.

Modified:
    trunk/gcc/lto/ChangeLog
    trunk/gcc/lto/lto-symtab.c

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #41 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
That doesn't fix this bug, because the symbol still gets optimized away with
-O3:

markus@x4 tmp % g++ -flto -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii
markus@x4 tmp % nm a.out | c++filt| grep "transferNodesFromList"
markus@x4 tmp % g++ -flto -fPIC -shared -fno-rtti -O2 BasicBlock.ii Function.ii
markus@x4 tmp % nm a.out | c++filt| grep "transferNodesFromList"
0000000000000ad0 W llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)
0000000000000ad0 t llvm::SymbolTableListTraits<llvm::BasicBlock,
llvm::Function>::transferNodesFromList(llvm::ilist_traits<llvm::BasicBlock>&,
llvm::ilist_iterator<llvm::BasicBlock>, llvm::ilist_iterator<llvm::BasicBlock>)
[clone .localalias.0]

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #42 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Ah, I see what's wrong. The following patch fixes the issue:

diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
index 6b2d488ed090..bc192d0467b3 100644
--- a/gcc/lto/lto-partition.c
+++ b/gcc/lto/lto-partition.c
@@ -98,6 +98,7 @@ get_symbol_class (symtab_node *node)
      Those do not need duplication.  */
   if (DECL_COMDAT (node->decl)
       && !node->force_output
+      && !node->forced_by_abi
       && !symtab_used_from_object_file_p (node))
     return SYMBOL_DUPLICATE;

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #43 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 32045
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32045&action=edit
new testcase

r207489 fixes the original issue. Thanks.

But llvm still doesn't build with -flto:

FAILED: : && /usr/bin/g++   -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wno-may
be-uninitialized -Wnon-virtual-dtor -fno-rtti -O3 -DNDEBUG -pipe -march=native
-flto=4 
-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=all,--icf-iterations=3
utils/
FileCheck/CMakeFiles/FileCheck.dir/FileCheck.cpp.o  -o bin/FileCheck  -lrt -ldl
-lcurses -lpthread -lz lib/libLLVMSupport.so -lpthread -lrt -ldl -lcurses
-lpthread -lz -Wl,-r
path,/var/tmp/llvm_build/lib && :
lib/libLLVMSupport.so: error: undefined reference to 'void*
llvm::object_creator<llvm::StringMap<llvm::Timer, llvm::MallocAllocator> >()'
lib/libLLVMSupport.so: error: undefined reference to 'void*
llvm::object_creator<std::string>()'
lib/libLLVMSupport.so: error: undefined reference to 'void*
llvm::object_creator<std::vector<llvm::Timer*, std::allocator<llvm::Timer*> >
>()'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

In this case lto produces an undefined symbol for e.g.:
 42902 static ManagedStatic<std::vector<Timer*> > ActiveTimers; 
Before r207489 the symbol was weak.

markus@x4 llvm_build % g++ -fPIC -O3 -flto -shared Timer.ii
markus@x4 llvm_build % nm a.out | grep
_ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_EEEEPvv
                 U _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_EEEEPvv

markus@x4 llvm_build % g++ -fPIC -O3 -flto -flto-partition=none -shared
Timer.ii
markus@x4 llvm_build % nm a.out | grep
_ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_EEEEPvv
0000000000003770 W _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_EEEEPvv

markus@x4 llvm_build % g++ -fPIC -O3 -shared Timer.ii
markus@x4 llvm_build % nm a.out | grep
_ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_EEEEPvv
0000000000008dc0 W _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_EEEEPvv
markus@x4 llvm_build %

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #44 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
index da76b10511f0..e47679239d84 100644
--- a/gcc/lto/lto-partition.c
+++ b/gcc/lto/lto-partition.c
@@ -97,7 +97,7 @@ get_symbol_class (symtab_node *node)
   /* Linker discardable symbols are duplicated to every use unless they are
      keyed.
      Keyed symbols or those.  */
-  if (DECL_ONE_ONLY (node->decl)
+  if ((DECL_COMDAT (node->decl) || DECL_ONE_ONLY (node->decl))
       && !node->force_output
       && !node->forced_by_abi
       && !symtab_used_from_object_file_p (node))

fixes the issue for me. With this LLVM-3.4 now compiles fine with LTO. 
(LLVM trunk build still fails, but it looks like an LLVM bug to me.)

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #46 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 32067
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32067&action=edit
Path I am testing

Hi,
this is patch I am testing. It synchronizes the logic in lto-cgraph.c and
ipa-partition.c
It seems I also forgot to commit very old patch for setting
used_from_other_partition flag correctly, with current code we probably can
trigger undefined symbol with COMDAT and cross-partition devirtualization. I
will try to look into that next.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #47 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Feb  7 02:27:05 2014
New Revision: 207589

URL: http://gcc.gnu.org/viewcvs?rev=207589&root=gcc&view=rev
Log:

    PR ipa/59469
    * lto-cgraph.c (lto_output_node): Use
    symtab_get_symbol_partitioning_class.
    (lto_output_varpool_node): likewise.
    (symtab_get_symbol_partitioning_class): Move here from
    lto/lto-partition.c
    * cgraph.h (symbol_partitioning_class): Likewise.
    (symtab_get_symbol_partitioning_class): Declare.

    * lto-partition.c (symbol_class): Move to cgraph.h
    (get_symbol_class): Move to symtab.c
    (add_references_to_partition, add_symbol_to_partition_1,
    lto_max_map, lto_1_to_1_map, lto_balanced_map,
    lto_promote_cross_file_statics): Update.

Modified:
    trunk/gcc/cgraph.h
    trunk/gcc/lto-cgraph.c
    trunk/gcc/lto/ChangeLog
    trunk/gcc/lto/lto-partition.c

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #48 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Feb  7 02:27:37 2014
New Revision: 207590

URL: http://gcc.gnu.org/viewcvs?rev=207590&root=gcc&view=rev
Log:

    PR ipa/59469
    * lto-cgraph.c (lto_output_node): Use
    symtab_get_symbol_partitioning_class.
    (lto_output_varpool_node): likewise.
    (symtab_get_symbol_partitioning_class): Move here from
    lto/lto-partition.c
    * cgraph.h (symbol_partitioning_class): Likewise.
    (symtab_get_symbol_partitioning_class): Declare.

Modified:
    trunk/gcc/ChangeLog

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #49 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Feb  7 02:28:33 2014
New Revision: 207591

URL: http://gcc.gnu.org/viewcvs?rev=207591&root=gcc&view=rev
Log:

    PR ipa/59469
    * lto-cgraph.c (lto_output_node): Use
    symtab_get_symbol_partitioning_class.
    (lto_output_varpool_node): likewise.
    (symtab_get_symbol_partitioning_class): Move here from
    lto/lto-partition.c
    * cgraph.h (symbol_partitioning_class): Likewise.
    (symtab_get_symbol_partitioning_class): Declare.

Modified:
    trunk/gcc/symtab.c

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #50 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Hope so, this PR was quite persistent ;)