http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
Bug #: 56312
Summary: Firefox 20.0a1 compilation with enabled LTO fails
Classification: Unclassified
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
--- Comment #1 from Martin Liška 2013-02-28
18:31:05 UTC ---
I patched following two files with __attribute__ ((used)) which helped to go
further, having a new issue:
/home/marxin/Programming/firefox/xpcom/components/nsComponentManager.cpp: In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
--- Comment #3 from Martin Liška 2013-03-02
17:37:31 UTC ---
I just run it in debugger giving me exactly the same stack trace, so
can_refer_decl_in_current_unit_p is the place.
Martin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
--- Comment #6 from Martin Liška 2013-03-12
13:31:06 UTC ---
Hello Jan, there's a link to dump:
https://mega.co.nz/#!bBF3kBSI!JPkMhRtHgUAx_lUw-VctVB0llul3BSrad2dpF9_6yJQ
(extracted size is about 16GB)
Could you please paste your .mozconfig fil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
--- Comment #7 from Martin Liška 2013-03-23
23:42:28 UTC ---
The problem was caused by bad usage of gcc-ar and gcc-runlib that were actually
not used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Bug #: 57038
Summary: Latest libreoffice compilation fails with enabled LTO
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #2 from Martin Liška 2013-04-26
09:23:58 UTC ---
So the symbol is really external :
c++filt:
std::_Tuple_impl<0ul, int const&>::_Tuple_impl()
dump_symbol_node:
_ZNSt11_Tuple_implILm0EIRKiEEC1Ev/279814 (__comp_ctor ) @0x7fd6b26766f0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #3 from Martin Liška 2013-05-03
11:20:00 UTC ---
lto-partition.c:265 (add_symbol_to_partition)
c++filt:
std::_Tuple_impl<0ul, int const&>::_Tuple_impl()
dump_symtab_node:
_ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (_ZNSt11_Tuple_impl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #5 from Martin Liška 2013-05-03
12:43:56 UTC ---
Looks like the problem has many occurrences in CLucene:
_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev/146876
(_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #6 from Martin Liška 2013-05-03
12:44:44 UTC ---
Created attachment 30020
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30020
FieldCacheImpl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #8 from Martin Liška 2013-05-03
13:07:56 UTC ---
Flags:
g++ -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE
-DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=410 -DUNIX -DUNX -DX86_64 -D_PTHREADS
-D_REENTRANT -DRTL_USING -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #10 from Martin Liška 2013-05-03
15:19:08 UTC ---
Hi,
you are right, the symbol is also missing in FieldCacheImpl.o.
Unlike FieldCacheImpl.o, propagg.o really contains symbol:
_ZNSt11_Tuple_implILm0EJRKiEEC1Ev
I'm going to attac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025
--- Comment #5 from Martin Liška 2013-05-03
15:20:17 UTC ---
Created attachment 30024
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30024
Preprocessed propagg.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #11 from Martin Liška 2013-05-03
15:22:15 UTC ---
Created attachment 30025
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30025
Preprocessed propag.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #13 from Martin Liška 2013-05-03
16:59:42 UTC ---
I attached build log where compilation is aborted after calling
add_symbol_to_partition_1 of FieldCacheImpl.o.
If it is not useful, please tell me how to provide more verbose details
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #14 from Martin Liška 2013-05-03
17:00:19 UTC ---
Created attachment 30027
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30027
Build log1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
Bug #: 57208
Summary: Latest chromium compilation fails with enabled LTO
[4.8.1/4.9.0]
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #1 from Martin Liška 2013-05-08
12:32:24 UTC ---
Created attachment 30054
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30054
Savetemps dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #2 from Martin Liška 2013-05-08
12:32:51 UTC ---
Created attachment 30055
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30055
common.gypi - build configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #17 from Martin Liška ---
I tried to apply suggested patch, but following gcc_assert was thrown:
https://github.com/marxin/gcc/blob/master/gcc/lto/lto-partition.c#L564
Callstack:
[build CXX] store/source/stortree.cxx
lto1: internal c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #20 from Martin Liška ---
Looks like the compilation goes further, but another gcc_assert is reached:
0x51f015 add_symbol_to_partition_1
../../gcc/lto/lto-partition.c:187
0x51f5ba lto_balanced_map()
../../gcc/lto/lto-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #23 from Martin Liška ---
The patch fixed weakrefs problems.
Compilation goes further and some undefined stuff in libreoffice is met:
https://bugs.freedesktop.org/show_bug.cgi?id=61627
I think this gcc bug could be closed.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Andi Kleen is maintaining Linux kernel LTO branch:
https://github.com/andikleen/linux-misc
Repository version:
5c1e0bc49249c3ff44849a8f72e6cccd1486f38f
GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #3 from Martin Liška ---
I had a problem with linker, looks like chrome build system uses both linkers.
I hacked build system to use just ld.bfd.
gcc revision: 197652. I know it's about 2 months old, same error is given by
gcc from ab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #4 from Martin Liška ---
gcc --version: HEAD (June 3rd, 2013)
Failure:
g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-O1
-Wl,--as-needed -flto -fno-fat-lto-objects -o protoc -Wl,--start-group
obj/third_party/protob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #6 from Martin Liška ---
I've just tested latest gcc and the same message is still received by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #7 from Martin Liška ---
I've updated to latest gcc, all previous bugs are irrelevant: I mixed different
-Ox cflags and chromium build system is full of hacks (they use gold as a
primary linker, but bfd is used for some stuff, I used j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #8 from Martin Liška ---
Sorry, comment was not added to related linker kernel bug 57483.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #1 from Martin Liška ---
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #9 from Martin Liška ---
Simple error case:
/tmp/x.c
char dnet_ntoa();
int main() {
dnet_ntoa()
; return 0; }
gcc -flto /tmp/x.c
Result:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #2 from Martin Liška ---
Works for me, could be marker as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #15 from Martin Liška ---
I did a small workaround for ELF overflow: --param lto-partitions=64.
Following errors were met:
`_ZN10disk_cache15SimpleEntryImpl17WriteDataInternalEiiPN3net8IOBufferEiRKN4base8CallbackIFviEEEb'
referenced i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #16 from Martin Liška ---
Looks like ld.gold has a problem with large amount of files:
FAILED: flock linker.lock g++ -Wl,-z,now -Wl,-z,relro -pthread
-Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param
lto-parti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #17 from Martin Liška ---
I created a bug for gold linker in binutils bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=15660
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #26 from Martin Liška ---
Unit tests error:
Program received signal SIGSEGV, Segmentation fault.
0x2aaab39189ed in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
(gdb) bt
#0 0x2aaab39189ed i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #20 from Martin Liška ---
Link to ltrans16.cgraph dump:
https://docs.google.com/file/d/0B0pisUJ80pO1c0JTTmR5Z1pQb28/edit?usp=sharing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #28 from Martin Liška ---
Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received
is marked with '>', address: 0x2aaab390c19d
+
B+ ¦0x2aaab390c180 <_ZN10ScDocument7CalcAllEv> push %r15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #21 from Martin Liška ---
Ltrans grep
marxin@marxinbox /ssd/chrome-dumps $ grep
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi chrome.ltrans*
Binary file chrome.ltrans16.o matches
chrome.ltrans16.s:leaq
_ZN3net12_GLOBAL_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #22 from Martin Liška ---
Created attachment 30340
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30340&action=edit
chrome.ltrans16.s
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
SandboxSyscall calls SyscallAsm that is an assembler function defined in the
same file: syscall.cc.
dump grep:
grep SyscallAsm *:
out/Release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #28 from Martin Liška ---
Patch solved the problem for chromium ;) I will test libreoffice tomorrow.
(In reply to Martin Jambor from comment #27)
> Created attachment 30355 [details]
> Proposed patch
>
> I'd suggest this (yet unteste
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Chrome ltrans3 compilation fails due to:
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c: In function
‘vp8_get_compressed_data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726
--- Comment #1 from Martin Liška ---
Created attachment 30373
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30373&action=edit
onyx_if.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #2 from Martin Liška ---
Created attachment 30374
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30374&action=edit
syscall.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #3 from Martin Liška ---
Created attachment 30375
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30375&action=edit
Preprocessed syscall.cc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Latest firefox could not be compiled due to always inline error.
/ssd/firefox/js/src/jsapi.h: In function ‘js::regexp_exec(JSContext*, unsigned
int, JS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
--- Comment #1 from Martin Liška ---
Created attachment 30379
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30379&action=edit
RegExp.cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
--- Comment #2 from Martin Liška ---
Created attachment 30380
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30380&action=edit
jsapi.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #32 from Martin Liška ---
Sorry for late answer, proposed patch works for me.
Thanks,
Martin
(In reply to Ian Lance Taylor from comment #10)
> Created attachment 30323 [details]
> Possible patch
>
> Can you see if this patch fixes t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Hello,
I've encountered a new bug that was introduced by SVN commit: 204414.
Program: gimp
c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #3 from Martin Liška ---
I've seen the same problem also in Inkscape. I will try to create a testcase.
Would it be possible Jeffrey to build one of these programs?
Thanks,
Martin
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Created attachment 31284
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31284&action=edit
Dump
Test: 447.dealIII
Command line:
home
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Hello,
I encountered a bug connected to combining -fprofile-generate and -O2.
Command line:
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #9 from Martin Liška ---
Hello,
thank you for the hotfix that repaired switch/case missing return value.
Actually I was told by Jan to reproduce the functionality from varasm.c that I
was able to bootstrap and test.
The idea of re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #7 from Martin Liška ---
Patches helped me!
First one was sufficient for my simplified case (~800 files), but it was
necessary to add second one for chromium.
Will you add this changes to mainline or should I create a patch?
Thanks,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #4 from Martin Liška ---
Hm, it looks that there's an usage of top-level function chromium binary:
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #10 from Martin Liška ---
Second part of suggested patch is sufficient.
ps auxf:
marxin 20293 0.0 0.0 8604 1200 pts/0S17:27 0:00 | \_
c++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L.
-Wl,-
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
I do compile Chromium with LTO and there's ICE with enormous call stack:
gcc --version:
gcc (GCC) 4.9.0 20140313 (experimental)
ld --version:
GNU gold (GNU Bin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #2 from Martin Liška ---
Reduced input object files to ~800, bt consists of ~66K frames.
gdb:
(gdb) bt 10
#0 0x005cec2c in lookup_page_table_entry (p=) at ../../gcc/ggc-page.c:584
#1 0x005cfc5e in ggc_set_mark (p=0x7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #3 from Martin Liška ---
Created attachment 32374
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32374&action=edit
gtype-lto.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #4 from Martin Liška ---
Created attachment 32375
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32375&action=edit
bt 1000
67 matches
Mail list logo
