[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-19 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #10 from Martin Liška marxin.liska at gmail dot com ---
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,-uIsHeapProfilerRunning,-uProfilerStart
-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22Init
marxin   20294  0.0  0.0   8128   692 pts/0S17:27   0:00  |  
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/collect2
-plugin /home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.
marxin   20295  1.1  7.2 3881556 1181360 pts/0 S17:27   0:03  |
  \_
/home/marxin/Programming/bin/gcc/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld
-plugin /home/marxin/Programming/bi
marxin   20412  0.0  0.1  34448 27212 pts/0S17:28   0:00  |
  \_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
@/tmp/ccw1zmZQ
marxin   20413  0.0  0.0  12060  4548 pts/0S17:28   0:00  |
  \_ c++ @/tmp/ccH68rYD.args
marxin   20414 23.7 33.4 5533676 5489912 pts/0 t17:28   0:54  |
  \_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x8

ps ax | grep 20414:
20414 pts/0t  0:54
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x86-64 -msse2
-mssse3 -msse -mmmx -m64 -mtune=generic -march=x86-64 -auxbase
chrome_initial.chrome_exe_main_aura -O3 -fno-trapv -fno-exceptions -fPIC
-fno-fat-lto-objects -fltrans-output-list=/tmp/ccqDrHsV.ltrans.out -fwpa=9
-fresolution=/tmp/ccufR16A.res @/tmp/cc13JyyZ

GDB:
#1409777 0x006b3b11 in gt_ggc_m_P9tree_node4htab (x_p=0x7f0f55752850)
at gtype-desc.c:3185
(gdb) p *x
$2 = {hash_f = 0x75a1f0 libfunc_decl_hash(void const*), eq_f = 0x75a200
libfunc_decl_eq(void const*, void const*), del_f = 0x0, entries =
0x7f0f54390a00, size = 61, n_elements = 17, n_deleted = 0, searches = 17,
collisions = 4, 
  alloc_f = 0x681250 ggc_cleared_alloc_ptr_array_two_args(unsigned long,
unsigned long), free_f = 0x549db0 ggc_free(void*), alloc_arg = 0x0,
alloc_with_arg_f = 0x0, free_with_arg_f = 0x0, size_prime_index = 3}
down iterations:
(gdb) p x-generic-base-code
$7 = FUNCTION_DECL
$8 = FUNCTION_TYPE
$9 = INTEGER_TYPE
$10 = INTEGER_CST
$11 = INTEGER_TYPE
$12 = INTEGER_CST
$13 = INTEGER_TYPE
$14 = POINTER_TYPE
$15 = POINTER_TYPE
$16 = POINTER_TYPE
$17 = POINTER_TYPE
$18 = POINTER_TYPE
$19 = INTEGER_TYPE

Hope it will help.
Martin

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-18 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #7 from Martin Liška marxin.liska at gmail dot com ---
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,
Martin

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

2014-03-18 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

--- Comment #4 from Martin Liška marxin.liska at gmail dot com ---
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/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::SandboxDie(char const*, char const*, int): error: undefined
reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Trap::SigSys(int, siginfo_t*, void*): error: undefined reference to
'SyscallAsm'


SyscallAsm:
namespace playground2 {

  asm volatile(
# 76 ../../sandbox/linux/seccomp-bpf/syscall.cc
.text\n
.align 16, 0x90\n
.type SyscallAsm, @function\n
 SyscallAsm:.cfi_startproc\n




test %rax, %rax\n
jge  1f\n


call 0f;   .cfi_adjust_cfa_offset  8\n
  0:pop  %rax; .cfi_adjust_cfa_offset -8\n
addq $2f-0b, %rax\n
ret\n




  1:movq  0(%r12), %rdi\n
movq  8(%r12), %rsi\n
movq 16(%r12), %rdx\n
movq 24(%r12), %r10\n
movq 32(%r12), %r8\n
movq 40(%r12), %r9\n

syscall\n

  2:ret\n
.cfi_endproc\n
  9:.size SyscallAsm, 9b-SyscallAsm\n
# 172 ../../sandbox/linux/seccomp-bpf/syscall.cc
  );

If it's not supported feature, how could we handle such situation in LTO?
Assembler functions are commong in all kind video/audio codecs which are often
added to firefox/chromium.

Martin

[Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

Bug ID: 60553
   Summary: segfault in gt_ggc_mx_lang_tree_node in Chromium with
LTO
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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 Binutils 2.24.51.20140304) 1.11

(gdb) bt -20
#529301 0x005aae8e in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763af738) at
./gtype-lto.h:359
#529302 0x005aaf8b in gt_ggc_mx_lang_tree_node (x_p=0x7f5c644eedc8) at
./gtype-lto.h:378
#529303 0x005aae8e in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a40a8) at
./gtype-lto.h:359
#529304 0x005a92ef in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a70c0) at
./gtype-lto.h:55
#529305 0x005aae54 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a4150) at
./gtype-lto.h:357
#529306 0x005a92ef in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a73a0) at
./gtype-lto.h:55
#529307 0x005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a4690) at
./gtype-lto.h:356
#529308 0x005aadfd in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763c2c78) at
./gtype-lto.h:354
#529309 0x005aa694 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c7650fc00) at
./gtype-lto.h:263
#529310 0x00821c23 in gt_ggc_m_P9tree_node4htab (x_p=0x7f5c7775a850) at
gtype-desc.c:3185
#529311 0x007bfde6 in ggc_mark_root_tab (rt=0x10cd140
gt_ggc_r_gt_optabs_h) at ../../gcc/ggc-common.c:133
#529312 0x007c0281 in ggc_mark_roots () at ../../gcc/ggc-common.c:152
#529313 0x005d0c2a in ggc_collect () at ../../gcc/ggc-page.c:2077
#529314 0x005c32e7 in read_cgraph_and_symbols (nfiles=11258,
fnames=0x36701f0) at ../../gcc/lto/lto.c:3004
#529315 0x005c406a in lto_main () at ../../gcc/lto/lto.c:3406
#529316 0x009e4273 in compile_file () at ../../gcc/toplev.c:548
#529317 0x009e640a in do_compile () at ../../gcc/toplev.c:1914
#529318 0x009e6575 in toplev_main (argc=11283, argv=0x35fe750) at
../../gcc/toplev.c:1990
#529319 0x7f5c765b6be5 in __libc_start_main () from /lib64/libc.so.6
#529320 0x00587831 in _start () at ../sysdeps/x86_64/start.S:122

(gdb) bt 10
#0  0x005cec2c in lookup_page_table_entry (p=error reading variable:
Cannot access memory at address 0x7fffa80e8fc8) at ../../gcc/ggc-page.c:584
#1  0x005cfc5e in ggc_set_mark (p=0x7f5c399c1170) at
../../gcc/ggc-page.c:1467
#2  0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c1170) at
./gtype-lto.h:36
#3  0x005aae1a in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6f18) at
./gtype-lto.h:355
#4  0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6e70) at
./gtype-lto.h:375
#5  0x005aa4b8 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c10b8) at
./gtype-lto.h:246
#6  0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c60a8) at
./gtype-lto.h:374
#7  0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf5e8) at
./gtype-lto.h:375
#8  0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bae60) at
./gtype-lto.h:243
#9  0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf348) at
./gtype-lto.h:374

I don't know what to dump, if you are interested I can add all kind info you
need.


[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #2 from Martin Liška marxin.liska at gmail dot com ---
Reduced input object files to ~800, bt consists of ~66K frames.

gdb:
(gdb) bt 10
#0  0x005cec2c in lookup_page_table_entry (p=error reading variable:
Cannot access memory at address 0x7fff63d42ff8) at ../../gcc/ggc-page.c:584
#1  0x005cfc5e in ggc_set_mark (p=0x7feaf406c020) at
../../gcc/ggc-page.c:1467
#2  0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7feaf406c020) at
./gtype-lto.h:36
#3  0x005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec684bd0) at
./gtype-lto.h:356
#4  0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec6ad398) at
./gtype-lto.h:243
#5  0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68af18) at
./gtype-lto.h:374
#6  0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68c2a0) at
./gtype-lto.h:375
#7  0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec695e60) at
./gtype-lto.h:243
#8  0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec69a0a8) at
./gtype-lto.h:374
#9  0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec697d20) at
./gtype-lto.h:375

#2  0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7feaf406c020) at
./gtype-lto.h:36
36  while (ggc_test_and_set_mark (xlimit))
(gdb) print (*x).generic.base
$20 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, 
  public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0, 
  saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#3  0x005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec684bd0) at
./gtype-lto.h:356
356  gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.size);
(gdb) print (*x).generic.base
$21 = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, 
  public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0, 
  saturating_flag = 0, unsigned_flag = 1, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 256, version = 256}}
(gdb) up
#4  0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec6ad398) at
./gtype-lto.h:243
243  gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.common.typed.type);
(gdb) print (*x).generic.base
$22 = {code = TYPE_DECL, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, 
  public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0, 
  saturating_flag = 0, unsigned_flag = 1, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 256, version = 256}}
(gdb) up
#5  0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68af18) at
./gtype-lto.h:374
374  gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.name);
(gdb) print (*x).generic.base
$23 = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 1, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, 
  public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0, 
  saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#6  0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68c2a0) at
./gtype-lto.h:375
375  gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.next_variant);
(gdb) print (*x).generic.base
$24 = {code = RECORD_TYPE, side_effects_flag = 0

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #3 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 32374
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32374action=edit
gtype-lto.h

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #4 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 32375
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32375action=edit
bt 1000

[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin

2013-12-20 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541

--- Comment #9 from Martin Liška marxin.liska at gmail dot com ---
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 reordering pass is to order all functions that are seen during
instrumentation run and are executed during start-up of an application.

So that, we do not build separate sections for .text, .text.hot and
.text.startup. On the other hand: any execute function should not live in
.text.unlikely and .text.startup. If so, it means that we miss profile info and
these functions can be identified during debugging process.

I am not familiar with darwin format, Jan do you know what could cause problem?

[Bug c++/59265] New: Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

2013-11-23 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

Bug ID: 59265
   Summary: Segmentation fault in ipa_note_param_call for
-fprofile-use in SPEC CPU2006
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: 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=31284action=edit
Dump

Test: 447.dealIII

Command line:
home/marxin/gcc-mirror/bin/g++ -c -o mapping_q.o -DSPEC_CPU -DNDEBUG  -Iinclude
-DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3  -fno-strict-aliasing
-fpeel-loops -ffast-math -march=native -O2 -fprofile-use=/tmp/spec2006  
-DSPEC_CPU_LP64   mapping_q.cc -fdump-ipa-all
In file included from mapping_q.cc:23:0:
include/grid/tria_boundary.h: In member function 'unsigned int
MappingQdim::InternalData::memory_consumption() const [with int dim = 3]':
include/grid/tria_boundary.h:280:7: internal compiler error: Segmentation fault
 class StraightBoundary : public Boundarydim
   ^
0x93e9ff crash_signal
../../gcc/toplev.c:336
0x80097f ipa_note_param_call
../../gcc/ipa-prop.c:1753
0x80afae ipa_analyze_virtual_call_uses
../../gcc/ipa-prop.c:2007
0x80afae ipa_analyze_call_uses
../../gcc/ipa-prop.c:2031
0x80afae ipa_analyze_stmt_uses
../../gcc/ipa-prop.c:2045
0x80afae ipa_analyze_params_uses
../../gcc/ipa-prop.c:2144
0x80afae ipa_analyze_node(cgraph_node*)
../../gcc/ipa-prop.c:2195
0xd7a4d7 ipcp_generate_summary
../../gcc/ipa-cp.c:3616
0x89ffbd execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc/passes.c:2013
0x6db1ed ipa_passes
../../gcc/cgraphunit.c:2022
0x6db1ed compile()
../../gcc/cgraphunit.c:2126
0x6db304 finalize_compilation_unit()
../../gcc/cgraphunit.c:2280
0x58bdd6 cp_write_global_declarations()

gcc version: trunk@205309

uname -a
Linux marxinbox 3.7.4-gentoo #6 SMP Mon Sep 30 20:53:52 CEST 2013 x86_64 AMD
FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux

I attached dumps.

Martin


[Bug c++/59266] New: Segmentation fault in ipa-devirt.c (record_target_from_binfo) for Inkscape

2013-11-23 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59266

Bug ID: 59266
   Summary: Segmentation fault in ipa-devirt.c
(record_target_from_binfo) for Inkscape
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: 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/freetype2  -pthread -DORBIT2=1
-I/usr/include/gnome-vfs-2.0 -I/usr/lib64/gnome-vfs-2.0/include
-I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include   -fopenmp -I/usr/include/ImageMagick   
-I/usr/include/libwpg-0.2 -I/usr/include/libwpd-0.9 -I/usr/include/poppler 
 -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm  
-DPOTRACE=\potrace\ -pthread -I/usr/include/gdkmm-2.4
-I/usr/lib64/gdkmm-2.4/include -I/usr/include/giomm-2.4
-I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4
-I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-2.0
-I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib64/sigc++-2.0/include -I/usr/include/cairomm-1.0
-I/usr/lib64/cairomm-1.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15
-I/usr/include/libdrm -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtkmm-2.4
-I/usr/lib64/gtkmm-2.4/include -I/usr/include/atkmm-1.6
-I/usr/include/gtk-unix-print-2.0 -I/usr/include/libxml2
-I/usr/include/gtkspell-2.0   -I../cxxtest  -I./bind/javainc
-I./bind/javainc/linux   -Werror=format-security -DG_DISABLE_SINGLE_INCLUDES
-Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2   -Wpointer-arith
-Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter
-g -O2 -fopenmp -MT dom/svgreader.o -MD -MP -MF $depbase.Tpo -c -o
dom/svgreader.o dom/svgreader.cpp mv -f $depbase.Tpo $depbase.Po
-fdump-ipa-all --verbose
cc1plus: internal compiler error: in record_target_from_binfo, at
ipa-devirt.c:664
0x7f0ae0 record_target_from_binfo
../../gcc/ipa-devirt.c:664
0x7f09cf record_target_from_binfo
../../gcc/ipa-devirt.c:684
0x7f09cf record_target_from_binfo
../../gcc/ipa-devirt.c:684
0x7f09cf record_target_from_binfo
../../gcc/ipa-devirt.c:684
0x7f0b5e possible_polymorphic_call_targets_1
../../gcc/ipa-devirt.c:708
0x7f0ba6 possible_polymorphic_call_targets_1
../../gcc/ipa-devirt.c:714
0x7f0ba6 possible_polymorphic_call_targets_1
../../gcc/ipa-devirt.c:714
0x7f23f7 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**)
../../gcc/ipa-devirt.c:1295
0x6da626 possible_polymorphic_call_targets
../../gcc/ipa-utils.h:114
0x6da626 walk_polymorphic_call_targets
../../gcc/cgraphunit.c:858
0x6da626 analyze_functions
../../gcc/cgraphunit.c:1031
0x6db2f0 finalize_compilation_unit()
../../gcc/cgraphunit.c:2271
0x58bdd6 cp_write_global_declarations()
../../gcc/cp/decl2.c:4431

I can't create any dumps by adding -fdump-ipa-all. If you advise, I can create
more detail dump.

Thanks,
Martin


[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

2013-11-12 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083

--- Comment #3 from Martin Liška marxin.liska at gmail dot com ---
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

[Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

2013-11-11 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083

Bug ID: 59083
   Summary: -fisolate-erroneous-paths produces illegal instruction
with enabled -fprofile-generate
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  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
commit 88ecd59c3436d302b644a5d25c1938c0e7b60ae0
Author: Michael Natterer mi...@gimp.org
Date:   Tue Feb 5 20:43:53 2013 +0100

GCC: 204414

uname -a:
Linux marxinbox 3.7.4-gentoo #6 SMP Mon Sep 30 20:53:52 CEST 2013 x86_64 AMD
FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux

Build flags:
CFLAGS=-flto=9 -fno-fat-lto-objects -O2 -fprofile-generate

When I added -fno-isolate-erroneous-paths the program run correctly.

Stacktrace:

│0x988226 windows_actions_dock_window_added+646addq  
$0x1,0x6a8732(%rip)# 0x1030960
__gcov0.gimp_action_group_add_actions.lto_priv.4837+64   
   │   │0x98822e
windows_actions_dock_window_added+654addq   $0x1,0x6a87d2(%rip)  
 # 0x1030a08 __gcov0.gimp_action_group_add_actions.lto_priv.4837+232 
│   │0x988236
windows_actions_dock_window_added+662callq  0x820fa0
gimp_action_group_check_unique_action.lto_priv.5831  
   
 │   │0x98823b windows_actions_dock_window_added+667test   %eax,%eax 
   
  
│   │0x98823d windows_actions_dock_window_added+669jne0x988258
windows_actions_dock_window_added+696
   
 │   │0x98823f windows_actions_dock_window_added+671addq  
$0x1,0x6a8721(%rip)# 0x1030968
__gcov0.gimp_action_group_add_actions.lto_priv.4837+72   
   │   │0x988247
windows_actions_dock_window_added+679addq   $0x1,0x6a87b1(%rip)  
 # 0x1030a00 __gcov0.gimp_action_group_add_actions.lto_priv.4837+224 
│   │0x98824f
windows_actions_dock_window_added+687jmpq   0x988100
windows_actions_dock_window_added+352
   
 │   │0x988254 windows_actions_dock_window_added+692nopl   0x0(%rax) 
   
  
│   │0x988258 windows_actions_dock_window_added+696mov$0x5,%edx  
   
  │
  │0x98825d windows_actions_dock_window_added+701mov   
$0xb8b6f6,%esi 
   
  │   │0x988262 windows_actions_dock_window_added+706xor   
%edi,%edi  
   
  │   │0x988264 windows_actions_dock_window_added+708callq 
0x478da0 dcgettext@plt   
   
  │  │0x988269 windows_actions_dock_window_added+713ud2 
   
   
│   │0x98826bnopl  
0x0(%rax,%rax,1)   
   
  │   │0x988270 windows_actions_update_display_accelspush  
%r14   
   
  │   │0x988272 windows_actions_update_display_accels+2  mov   
%rdi,%r14

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2013-08-21 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

Martin Liška marxin.liska at gmail dot com changed:

   What|Removed |Added

 CC||marxin.liska at gmail dot com

--- Comment #189 from Martin Liška marxin.liska at gmail dot com ---
I've encountered problems connected with PGO:

gcc revision: 201894
firefox changeset:  143205:1d6bf2bd4003 (Aug 20, 2013)

I build instrumented binary without LTO and after that I use the profile for
LTO:
MYFLAGS=-flto=9 -fno-fat-lto-objects -ftoplevel-reorder -fprofile-use
-Wno-error=coverage-mismatch

I know that there are gcda files that are mentioned in this thread and were
removed by me:

jemalloc.gcda (makes sense)
ptsynch.gcda (likewise)

HashFunctions.gcda (?)
sqlite3.gcda (?)

After linking of sqlite3, there are many corrupted profiles like:
/ssd/firefox/js/src/gc/Marking.cpp
/ssd/firefox/js/src/frontend/BytecodeEmitter.cpp
/ssd/firefox/js/src/frontend/Interpreter.cpp
...

Example of an error:
/ssd/firefox/js/src/gc/Marking.cpp: In function
‘js::gc::IsAboutToBeFinalizedJSAtom(JSAtom**)bool [clone .isra.65]’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
 }
 ^
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 3-6 thought to be -81
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 3-4 thought to be 39667
/ssd/firefox/js/src/gc/Marking.cpp: In function
‘js::gc::IsAboutToBeFinalizedjs::UnownedBaseShape(js::UnownedBaseShape**)bool
[clone .isra.52]’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 3-6 thought to be -1
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 3-4 thought to be 41156
/ssd/firefox/js/src/gc/Marking.cpp: In function
‘MarkInternalJSAtom(JSTracer*, JSAtom**)void’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 9-14 thought to be -39
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 9-10 thought to be 180119
/ssd/firefox/js/src/gc/Marking.cpp: In function
‘MarkInternalJSObject(JSTracer*, JSObject**)void’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 11-18 thought to be -1
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 11-12 thought to be 49007
/ssd/firefox/js/src/gc/Marking.cpp: In member function ‘js::MarkStackunsigned
long::push(unsigned long)’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 4-6 thought to be -1
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 4-5 thought to be 1
/ssd/firefox/js/src/gc/Marking.cpp: In member function
‘js::GCMarker::drainMarkStack(js::SliceBudget)’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 3-4 thought to be -7
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 3-1 thought to be 7
/ssd/firefox/js/src/gc/Marking.cpp: In member function
‘js::ObjectImpl::slotSpan() const’:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
profile data is not flow-consistent
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 5-7 thought to be -1
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
number of executions for edge 5-6 thought to be 15965

Thank you,
Martin

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-07-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #32 from Martin Liška marxin.liska at gmail dot com ---
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 the problem?

[Bug lto/57726] New: LTO verify_flow_info: error: control flow in the middle of basic block

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726

Bug ID: 57726
   Summary: LTO verify_flow_info: error: control flow in the
middle of basic block
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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’:
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 6
 int vp8_set_internal_size(VP8_COMP *cpi, VPX_SCALING horiz_mode, VPX_SCALING
vert_mode)
 ^
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 6
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 6
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 64
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 73
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error:
control flow in the middle of basic block 103
../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: internal
compiler error: verify_flow_info failed
0x568b5d verify_flow_info()
../../gcc/cfghooks.c:260
0x88d734 cleanup_tree_cfg_noloop
../../gcc/tree-cfgcleanup.c:696
0x88d734 cleanup_tree_cfg()
../../gcc/tree-cfgcleanup.c:745
0x7b16c4 execute_function_todo
../../gcc/passes.c:1927
0x7b1fcd execute_todo
../../gcc/passes.c:2002
0x7b3ba9 execute_one_ipa_transform_pass
../../gcc/passes.c:2185
0x7b3ba9 execute_all_ipa_transforms()
../../gcc/passes.c:2215
0x58673e expand_function
../../gcc/cgraphunit.c:1584
0x58841c expand_all_functions
../../gcc/cgraphunit.c:1695
0x58841c compile()
../../gcc/cgraphunit.c:2029
0x50e3f1 lto_main()
../../gcc/lto/lto.c:3872

gcc --version:
gcc (GCC) 4.9.0 20130624 (experimental)

Link to all ltrans3 dump files:
https://docs.google.com/file/d/0B0pisUJ80pO1akhINVR1anpTbDg/edit?usp=sharing

Source file is attached.

Thanks,
Martin

[Bug lto/57726] LTO verify_flow_info: error: control flow in the middle of basic block

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726

--- Comment #1 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 30373
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30373action=edit
onyx_if.c

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

--- Comment #2 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 30374
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30374action=edit
syscall.cc

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

--- Comment #3 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 30375
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30375action=edit
Preprocessed syscall.cc

[Bug c++/57729] New: Always inline: indirect function call with a yet undetermined callee

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729

Bug ID: 57729
   Summary: Always inline: indirect function call with a yet
undetermined callee
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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::Value*)’:
/ssd/firefox/js/src/builtin/RegExp.cpp:307:1: error: inlining failed in call to
always_inline ‘IsRegExp(JS::Value const)’: indirect function call with a yet
undetermined callee
 IsRegExp(const Value v)
 ^
In file included from /ssd/firefox/js/src/jsprvtd.h:24:0,
 from /ssd/firefox/js/src/builtin/RegExp.h:10,
 from /ssd/firefox/js/src/builtin/RegExp.cpp:7:
/ssd/firefox/js/src/jsapi.h:707:5: error: called from here
 if (Test(thisv))
 ^

Code snippet:
JS_ALWAYS_INLINE bool
IsRegExp(const Value v)
{
return v.isObject()  v.toObject().isRegExpObject();
}


JSBool
js::regexp_exec(JSContext *cx, unsigned argc, Value *vp)
{
CallArgs args = CallArgsFromVp(argc, vp);
return CallNonGenericMethod(cx, IsRegExp, regexp_exec_impl, args);
}

I found out that problematic commit is: 200179.

[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729

--- Comment #1 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 30379
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30379action=edit
RegExp.cpp

[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729

--- Comment #2 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 30380
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30380action=edit
jsapi.h

[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729

Martin Liška marxin.liska at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Martin Liška marxin.liska at gmail dot com ---
Duplicate.

*** This bug has been marked as a duplicate of bug 57698 ***

[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox

2013-06-26 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698

Martin Liška marxin.liska at gmail dot com changed:

   What|Removed |Added

 CC||marxin.liska at gmail dot com

--- Comment #4 from Martin Liška marxin.liska at gmail dot com ---
*** Bug 57729 has been marked as a duplicate of this bug. ***

[Bug lto/57703] New: Assembler function definition moved to a different ltrans then call

2013-06-24 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

Bug ID: 57703
   Summary: Assembler function definition moved to a different
ltrans then call
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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/nacl_helper.ltrans1.047i.inline:call SyscallAsm
out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm
out/Release/nacl_helper.ltrans0.s:.type SyscallAsm, @function
out/Release/nacl_helper.ltrans0.s:SyscallAsm:.cfi_startproc
out/Release/nacl_helper.ltrans0.s:9:.size SyscallAsm, 9b-SyscallAsm
out/Release/nacl_helper.ltrans1.s:call SyscallAsm
out/Release/nacl_helper.ltrans1.045i.cp:call SyscallAsm

Linker error:
nacl_helper.ltrans1.ltrans.o: In function `playground2::SandboxSyscall(int,
long, long, long, long, long, long)':
nacl_helper.ltrans1.o:(.text+0x4503): undefined reference to `SyscallAsm'
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
nacl_helper.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined symbol
`SyscallAsm' can not be used when making a shared object; recompile with -fPIC
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: final
link failed: Bad value
collect2: error: ld returned 1 exit status

Dumps link:
https://docs.google.com/file/d/0B0pisUJ80pO1eFltWU9NUUZkaGM/edit?usp=sharing

When compiled with --param lto-partitions=1 no problem is encountered.


[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-24 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #28 from Martin Liška marxin.liska at gmail dot com ---
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 untested) patch.

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-22 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #21 from Martin Liška marxin.liska at gmail dot com ---
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__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rax
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  Called by:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (1.00 per call)
_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE.lto_priv.62289/8859580
(0.62 per call) 
chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591
(OnIOComplete) @0x7ff6f304a5f0
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  Called by:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (1.00 per call)
_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE.lto_priv.62289/8859580
(0.62 per call) 
chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591
(OnIOComplete) @0x7ff6f304a5f0
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591
(OnIOComplete) @0x7ff6f304a5f0
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.045i.cp:;; Function OnIOComplete
(_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, funcdef_no=1376,
decl_uid=894468, symbol_order=8859591)
chrome.ltrans29.047i.inline:;; Function OnIOComplete
(_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, funcdef_no=1376,
decl_uid=894468, symbol_order=8859591)
Binary file chrome.ltrans29.o matches
chrome.ltrans29.s:leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:.type   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, @function
chrome.ltrans29.s:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi:
chrome.ltrans29.s:.size   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi,
.-_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-22 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #22 from Martin Liška marxin.liska at gmail dot com ---
Created attachment 30340
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30340action=edit
chrome.ltrans16.s

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-06-21 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038

--- Comment #26 from Martin Liška marxin.liska at gmail dot com ---
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 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
#1  0x2aaab3a77516 in ScDocShell::DoHardRecalc(bool) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
#2  0x2f8df43e in ScFiltersTest::testContentXLS() () from
/ssd/libreoffice/workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_sc_filters_test.so
#3  0x2ab8614e in CppUnit::TestCaseMethodFunctor::operator()() const ()
from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#4  0x2ab813b1 in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const () from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#5  0x2c332800 in (anonymous namespace)::Prot::protect(CppUnit::Functor
const, CppUnit::ProtectorContext const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/unoexceptionprotector.so
#6  0x2ab813b1 in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const () from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#7  0x2ab78016 in CppUnit::DefaultProtector::protect(CppUnit::Functor
const, CppUnit::ProtectorContext const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#8  0x2ab813b1 in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const () from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#9  0x2ab8125b in CppUnit::ProtectorChain::protect(CppUnit::Functor
const, CppUnit::ProtectorContext const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#10 0x2ab9073a in CppUnit::TestResult::protect(CppUnit::Functor const,
CppUnit::Test*, std::string const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#11 0x2ab85c1e in CppUnit::TestCase::run(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#12 0x2ab86812 in
CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#13 0x2ab8669c in CppUnit::TestComposite::run(CppUnit::TestResult*) ()
from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#14 0x2ab86812 in
CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#15 0x2ab8669c in CppUnit::TestComposite::run(CppUnit::TestResult*) ()
from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#16 0x2ab94878 in
CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#17 0x2ab90518 in CppUnit::TestResult::runTest(CppUnit::Test*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#18 0x2ab94ac8 in CppUnit::TestRunner::run(CppUnit::TestResult,
std::string const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#19 0x004026aa in (anonymous namespace)::ProtectedFixtureFunctor::run()
const ()
#20 0x00402b27 in sal_main() ()
#21 0x0040226b in main ()

Output:
CalcAll called


Program received signal SIGSEGV, Segmentation fault.
0x2aaab390c19d in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so

Source code snippet:
void ScDocument::CalcAll()
{
puts(CalcAll called\n);
ClearLookupCaches();// Ensure we don't deliver zombie data.
puts(CalcAll called2\n);
bool bOldAutoCalc = GetAutoCalc();
puts(CalcAll called3\n);
SetAutoCalc( true );
puts(CalcAll called4\n);
TableContainer::iterator it = maTabs.begin();
puts(CalcAll called5\n);
for (; it != maTabs.end(); ++it)
if (*it)
(*it)-SetDirtyVar();
for (it = maTabs.begin(); it != maTabs.end(); ++it)
if (*it)
(*it)-CalcAll();
puts(CalcAll called6\n);
ClearFormulaTree();
puts(CalcAll called7\n);
SetAutoCalc( bOldAutoCalc );
puts(CalcAll called8\n);
}

Link to dumps:
https://docs.google.com/file/d/0B0pisUJ80pO1OFNEc2h4YWVwa2s/edit?usp=sharing

If you need assembler dumps, I can upload it.

Thanks,
Martin

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-21 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #20 from Martin Liška marxin.liska at gmail dot com ---
Link to ltrans16.cgraph dump:
https://docs.google.com/file/d/0B0pisUJ80pO1c0JTTmR5Z1pQb28/edit?usp=sharing

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-06-21 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038

--- Comment #28 from Martin Liška marxin.liska at gmail dot com ---
Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received
is marked with '', address: 0x2aaab390c19d 

+
B+ ¦0x2aaab390c180 _ZN10ScDocument7CalcAllEv  push   %r15
   
¦
   ¦0x2aaab390c182 _ZN10ScDocument7CalcAllEv+2push   %r14
   
¦
   ¦0x2aaab390c184 _ZN10ScDocument7CalcAllEv+4push   %r13
   
¦
   ¦0x2aaab390c186 _ZN10ScDocument7CalcAllEv+6push   %r12
   
¦
   ¦0x2aaab390c188 _ZN10ScDocument7CalcAllEv+8push   %rbp
   
¦
   ¦0x2aaab390c189 _ZN10ScDocument7CalcAllEv+9mov%rdi,%rbp   
   
¦
   ¦0x2aaab390c18c _ZN10ScDocument7CalcAllEv+12   lea0x21bc66(%rip),%rdi 
  # 0x2aaab3b27df9 
¦
   ¦0x2aaab390c193 _ZN10ScDocument7CalcAllEv+19   push   %rbx
   
¦
   ¦0x2aaab390c194 _ZN10ScDocument7CalcAllEv+20   sub$0x18,%rsp  
   
¦
   ¦0x2aaab390c198 _ZN10ScDocument7CalcAllEv+24   callq  0x2aaab33c8af0
puts@plt 
   
  ¦
  ¦0x2aaab390c19d _ZN10ScDocument7CalcAllEv+29   mov0x1c8(%rbp),%rbx
   
¦
   ¦0x2aaab390c1a4 _ZN10ScDocument7CalcAllEv+36   test   %rbx,%rbx   
   
¦
   ¦0x2aaab390c1a7 _ZN10ScDocument7CalcAllEv+39   je 0x2aaab390c29d
_ZN10ScDocument7CalcAllEv+285
   
  ¦
   ¦0x2aaab390c1ad _ZN10ScDocument7CalcAllEv+45   mov(%rbx),%r12 
   
¦
   ¦0x2aaab390c1b0 _ZN10ScDocument7CalcAllEv+48   mov0x8(%rbx),%rax  
   
¦
   ¦0x2aaab390c1b4 _ZN10ScDocument7CalcAllEv+52   test   %r12,%r12   
   
¦
   ¦0x2aaab390c1b7 _ZN10ScDocument7CalcAllEv+55   je 0x2aaab390c1f5
_ZN10ScDocument7CalcAllEv+117
   
  ¦
   ¦0x2aaab390c1b9 _ZN10ScDocument7CalcAllEv+57   mov(%r12,%rax,8),%r13  
   
¦
   ¦0x2aaab390c1bd _ZN10ScDocument7CalcAllEv+61   test   %r13,%r13   
   
¦
   ¦0x2aaab390c1c0 _ZN10ScDocument7CalcAllEv+64   je 0x2aaab390c1f5
_ZN10ScDocument7CalcAllEv+117
   
  ¦
   ¦0x2aaab390c1c2

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-20 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #15 from Martin Liška marxin.liska at gmail dot com ---
I did a small workaround for ELF overflow: --param lto-partitions=64.

Following errors were met:
`_ZN10disk_cache15SimpleEntryImpl17WriteDataInternalEiiPN3net8IOBufferEiRKN4base8CallbackIFviEEEb'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of obj/net/disk_cache/simple/net.simple_entry_impl.o (symbol
from plugin)
`_ZN10disk_cache15SimpleEntryImpl25CreationOperationCompleteERKN4base8CallbackIFviEEERKNS1_9TimeTicksE10scoped_ptrIPNS_22SimpleSynchronousEntryENS1_14DefaultDeleterISC_EEESA_IiNSD_IiEEEPPNS_5EntryE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of obj/net/disk_cache/simple/net.simple_entry_impl.o (symbol
from plugin)
`_ZN7content20ShaderDiskCacheEntry12OnOpCompleteEi' referenced in section
`.text' of chrome.ltrans16.ltrans.o: defined in discarded section `.text' of
obj/content/browser/gpu/content_browser.shader_disk_cache.o (symbol from
plugin)
`_ZN7content19TraceControllerImpl29OnTraceBufferPercentFullReplyEf' referenced
in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded section
`.text' of obj/content/browser/tracing/content_browser.trace_controller_impl.o
(symbol from plugin)
`_ZN7content19TraceControllerImpl15OnEndTracingAckERKSt6vectorISsSaISsEE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/content/browser/tracing/content_browser.trace_controller_impl.o (symbol
from plugin)
`_ZN3net15ViewCacheHelper12OnIOCompleteEi' referenced in section `.text' of
chrome.ltrans16.ltrans.o: defined in discarded section `.text' of
obj/net/url_request/net.view_cache_helper.o (symbol from plugin)
`_ZN15quota_internals19QuotaInternalsProxy17DidGetGlobalUsageEN5quota11StorageTypeEll'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/chrome/browser/ui/webui/quota_internals/browser_ui.quota_internals_proxy.o
(symbol from plugin)
`_ZN8appcache22AppCacheResponseWriter21OnCreateEntryCompleteEPPNS_26AppCacheDiskCacheInterface5EntryEi'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/webkit/support/../appcache/webkit_storage.appcache_response.o (symbol from
plugin)
`_ZN5media18AlsaPcmInputStream9ReadAudioEv' referenced in section `.text' of
chrome.ltrans16.ltrans.o: defined in discarded section `.text' of
obj/media/audio/linux/media.alsa_input.o (symbol from plugin)
`_ZN16sync_file_system20DriveFileSyncService34DidGetDirectoryContentForBatchSyncERKN4base8CallbackIFvNS_14SyncStatusCodeRK4GURLRKSslN11google_apis14GDataErrorCodeE10scoped_ptrINSD_12ResourceListENS1_14DefaultDeleterISG_EEE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/chrome/browser/sync_file_system/browser.drive_file_sync_service.o (symbol
from plugin)
`_ZN16sync_file_system5drive28LocalChangeProcessorDelegate19DidApplyLocalChangeERKN4base8CallbackIFvNS_14SyncStatusCodeN11google_apis14GDataErrorCodeES4_'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/chrome/browser/sync_file_system/drive/browser.local_change_processor_delegate.o
(symbol from plugin)
`_ZN8remoting22RectangleUpdateDecoder12OnPacketDoneEbN4base4TimeERKNS1_8CallbackIFvvEEE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/remoting/client/remoting_client.rectangle_update_decoder.o (symbol from
plugin)
`_ZN17AgentHostDelegate11OnBytesReadE13scoped_refptrIN3net8IOBufferEEi'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section
`.gnu.linkonce.t._ZN17AgentHostDelegate11OnBytesReadE13scoped_refptrIN3net8IOBufferEEi'
of obj/chrome/browser/devtools/debugger.devtools_adb_bridge.o (symbol from
plugin)
`_ZN8remoting8protocol16ConnectionToHost20OnChannelInitializedEb' referenced in
section `.text' of chrome.ltrans16.ltrans.o: defined in discarded section
`.text' of obj/remoting/protocol/remoting_protocol.connection_to_host.o (symbol
from plugin)
chrome.ltrans16.ltrans.o: In function
`base::Callbackbase::internal::BindStatebase::internal::FunctorTraitsvoid
(net::(anonymous namespace)::DnsTCPAttempt::*)(int)::RunnableType,
base::internal::FunctorTraitsvoid (net::(anonymous
namespace)::DnsTCPAttempt::*)(int)::RunType, void
(base::internal::CallbackParamTraitsbase::internal::UnretainedWrappernet::(anonymous
namespace)::DnsTCPAttempt ::StorageType)::UnboundRunType base::Bindvoid
(net::(anonymous namespace)::DnsTCPAttempt::*)(int),
base::internal::UnretainedWrappernet::(anonymous namespace)::DnsTCPAttempt
(void (net::(anonymous namespace)::DnsTCPAttempt::*)(int),
base::internal::UnretainedWrappernet::(anonymous namespace)::DnsTCPAttempt
const) [clone .constprop.12480]':
chrome.ltrans16.o:(.text+0x635f8

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-20 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #16 from Martin Liška marxin.liska at gmail dot com ---
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-partitions=64 -o chrome -Wl,--start-group
obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_main.o
obj/chrome/app/chrome.chrome_main_delegate.o obj/chrome/libinstaller_util.a
obj/media/libmedia_sse.a obj/third_party/icu/libicuuc.a
obj/third_party/libjingle/libjingle.a obj/skia/libskia_opts.a
obj/third_party/icu/libicudata.a obj/device/libdevice_media_transfer_protocol.a
obj/native_client/src/trusted/service_runtime/arch/x86/libservice_runtime_x86_common.a
obj/chrome/libservice.a obj/chrome/librenderer.a obj/webkit/support/libglue.a
obj/content/libcontent_worker.a obj/third_party/libwebp/libwebp_utils.a
obj/third_party/zlib/libminizip.a
obj/chrome/browser/performance_monitor/libperformance_monitor.a
obj/third_party/leveldatabase/libleveldatabase.a
obj/native_client/src/trusted/service_runtime/libenv_cleanser.a
obj/sandbox/libc_urandom_override.a obj/chrome/libbrowser.a
obj/ppapi/libppapi_host.a obj/sync/libsync_core.a obj/gpu/libgles2_cmd_helper.a
obj/third_party/smhasher/libcityhash.a
obj/third_party/libphonenumber/libphonenumber.a
obj/chrome/app/policy/libpolicy.a obj/webkit/support/libplugins_common.a
obj/native_client/src/trusted/validator_x86/libnccopy_x86_64.a
obj/webkit/support/libglue_common.a
obj/webkit/renderer/compositor_bindings/libwebkit_compositor_support.a
obj/third_party/smhasher/libmurmurhash3.a obj/content/libcontent_gpu.a
obj/native_client/src/trusted/threading/libthread_interface.a
obj/media/libmedia_mmx.a obj/ipc/libipc.a obj/third_party/libxslt/libxslt.a
obj/remoting/libremoting_client.a obj/third_party/ots/libots.a
obj/base/libsymbolize.a obj/native_client/src/trusted/validator/libvalidators.a
obj/chrome/libbrowser_extensions.a obj/skia/libskia_opts_ssse3.a
obj/third_party/protobuf/libprotobuf_lite.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform.a
obj/ui/surface/libsurface.a
obj/third_party/WebKit/Source/WebKit/chromium/libwebkit.a
obj/native_client/src/trusted/validator/x86/64/libncvalidate_x86_64.a
obj/third_party/jsoncpp/libjsoncpp.a obj/google_apis/libgoogle_apis.a
obj/chrome/libnacl.a
obj/third_party/libphonenumber/libphonenumber_without_metadata.a
obj/chrome/libdebugger.a obj/v8/tools/gyp/libv8_snapshot.a
obj/ui/native_theme/libnative_theme.a obj/third_party/libusb/libusb.a
obj/content/libcontent_common_child.a
obj/native_client/src/trusted/nacl_base/libnacl_base.a
obj/base/libbase_static.a obj/native_client/src/shared/imc/libimc.a
obj/chrome/libfeedback_proto.a
obj/components/libbrowser_context_keyed_service.a obj/components/libweb_modal.a
obj/chrome/libapps.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform_geometry.a
obj/components/libuser_prefs.a obj/content/libcontent_utility.a
obj/third_party/libevent/libevent.a obj/sandbox/libseccomp_bpf.a
obj/build/linux/libpci.a obj/ui/gl/libgl_wrapper.a
obj/third_party/mt19937ar/libmt19937ar.a
obj/third_party/angle/src/libtranslator_common.a
obj/ui/message_center/libmessage_center.a obj/third_party/libpng/libpng.a
obj/components/libwebdata_common.a obj/third_party/opus/libopus.a
obj/sync/libsync_notifier.a obj/ui/snapshot/libsnapshot.a
obj/native_client/src/trusted/validator/x86/libncval_base_x86_64.a
obj/webkit/support/libwebkit_media.a obj/third_party/libwebp/libwebp_dsp.a
obj/third_party/harfbuzz-ng/libharfbuzz-ng.a
obj/chrome/app/policy/libcloud_policy_proto_generated_compile.a
obj/base/allocator/liballocator_extension_thunks.a
obj/remoting/libremoting_jingle_glue.a
obj/native_client/src/trusted/service_runtime/libnacl_error_code.a
obj/third_party/snappy/libsnappy.a obj/cc/libcc.a
obj/third_party/libjingle/libjingle_p2p_constants.a
obj/third_party/cld/libcld.a obj/third_party/libxml/libxml2.a
obj/webkit/support/libplugins.a obj/chrome/libvariations_seed_proto.a
obj/remoting/proto/libchromotocol_proto_lib.a
obj/native_client/src/trusted/simple_service/libsimple_service.a
obj/chrome/libsync_file_system_proto.a obj/gpu/libdisk_cache_proto.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_html.a
obj/native_client/src/trusted/interval_multiset/libnacl_interval.a
obj/build/linux/libspeechd.a obj/sync/libsync_internal_api.a
obj/third_party/hunspell/libhunspell.a obj/chrome/libplugin.a
obj/ui/compositor/libcompositor.a obj/base/libbase_prefs.a
obj/ui/web_dialogs/libweb_dialogs.a
obj/native_client/src/trusted/desc/libdesc_wrapper.a
obj/third_party/angle/src/libpreprocessor.a obj/gpu/libgpu_ipc.a
obj/device/libdevice_usb.a obj/sandbox/libsuid_sandbox_client.a
obj/tools/json_schema_compiler/libapi_gen_util.a
obj/third_party/cacheinvalidation/libcacheinvalidation.a
obj/webkit/support/libwebkit_base.a obj/remoting/libremoting_base.a
obj/gpu

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-20 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #17 from Martin Liška marxin.liska at gmail dot com ---
I created a bug for gold linker in binutils bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=15660

[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO

2013-06-18 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483

--- Comment #2 from Martin Liška marxin.liska at gmail dot com ---
Works for me, could be marker as fixed.

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #7 from Martin Liška marxin.liska at gmail dot com ---
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 just bfd in my
compilation).

gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)

I finally reached WPA stage of LTO, memory usage was about 8GB for ld and 11 GB
for lto1.

lto1 was running for about 20 minutes and following error occured:

lto1: error: ELF section name out of range
lto1: internal compiler error: Segmentation fault
0x85e0bf crash_signal
../../gcc/toplev.c:333
0xd7f0dd htab_delete
../../libiberty/hashtab.c:419
0x50a41c lto_file_read
../../gcc/lto/lto.c:2824
0x50a41c read_cgraph_and_symbols
../../gcc/lto/lto.c:3401
0x50a41c lto_main()
../../gcc/lto/lto.c:3834
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.
lto-wrapper: g++ returned 1 exit status
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Do you have any ideas?

[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287

2013-06-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334

Martin Liška marxin.liska at gmail dot com changed:

   What|Removed |Added

 CC||marxin.liska at gmail dot com

--- Comment #7 from Martin Liška marxin.liska at gmail dot com ---
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.c:644
0x50afe4 lto_fixup_prevailing_decls
../../gcc/lto/lto.c:3220
0x50afe4 lto_fixup_decls
../../gcc/lto/lto.c:3284
0x50afe4 read_cgraph_and_symbols
../../gcc/lto/lto.c:3490
0x50afe4 lto_main()
../../gcc/lto/lto.c:3834

Dump (--save-temps --dump-ipa-all):
https://docs.google.com/file/d/0B0pisUJ80pO1X2w0eXgteHlvNDQ/edit?usp=sharing

[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287

2013-06-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334

--- Comment #8 from Martin Liška marxin.liska at gmail dot com ---
Sorry, comment was not added to related linker kernel bug 57483.

[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO

2013-06-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483

--- Comment #1 from Martin Liška marxin.liska at gmail dot com ---
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.c:644
0x50afe4 lto_fixup_prevailing_decls
../../gcc/lto/lto.c:3220
0x50afe4 lto_fixup_decls
../../gcc/lto/lto.c:3284
0x50afe4 read_cgraph_and_symbols
../../gcc/lto/lto.c:3490
0x50afe4 lto_main()
../../gcc/lto/lto.c:3834

Dump (--save-temps --dump-ipa-all):
https://docs.google.com/file/d/0B0pisUJ80pO1X2w0eXgteHlvNDQ/edit?usp=sharing

[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287

2013-06-17 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334

--- Comment #9 from Martin Liška marxin.liska at gmail dot com ---
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_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab.c:644
0x500719 lto_fixup_state
../../gcc/lto/lto.c:3257
0x50ab48 lto_fixup_decls
../../gcc/lto/lto.c:3290
0x50ab48 read_cgraph_and_symbols
../../gcc/lto/lto.c:3490
0x50ab48 lto_main()
../../gcc/lto/lto.c:3834

Should return for: gcc /tmp/x.c
/tmp/ccZU5rdy.o: In function `main':
x.c:(.text+0xa): undefined reference to `dnet_ntoa'
collect2: error: ld returned 1 exit status

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-05 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #6 from Martin Liška marxin.liska at gmail dot com ---
I've just tested latest gcc and the same message is still received by compiler.

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-03 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #3 from Martin Liška marxin.liska at gmail dot com ---
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 about 15th May 2013. Latest gcc suffers from a different failure that
will be added in following comment.

ld --version:
GNU ld (GNU Binutils) 2.23.52.20130526

Failure:
g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-O1
-Wl,--as-needed -flto -fno-fat-lto-objects -o mksnapshot.x64 -Wl,--start-group
obj/v8/src/mksnapshot.x64.mksnapshot.o obj/v8/tools/gyp/libv8_nosnapshot.x64.a
obj/v8/tools/gyp/libv8_base.x64.a  -Wl,--end-group -fdump-ipa-all --save-temps
lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:267
0x709296 inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*,
int*, bool)
../../gcc/ipa-inline-transform.c:263
0x6fb118 inline_small_functions
../../gcc/ipa-inline.c:1613
0x6fb118 ipa_inline
../../gcc/ipa-inline.c:1794
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.
lto-wrapper: g++ returned 1 exit status
[Leaving LTRANS mksnapshot.x64.ltrans.out]
[Leaving LTRANS /tmp/ccIviE1Z.args]
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

Dump:
https://docs.google.com/file/d/0B0pisUJ80pO1ck5sUmF5Q0k1Mmc/edit?usp=sharing

Thanks,
Martin

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

2013-06-03 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #4 from Martin Liška marxin.liska at gmail dot com ---
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/protobuf/src/google/protobuf/compiler/protoc.code_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.command_line_interface.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.plugin.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.plugin.pb.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.subprocess.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.zip_writer.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_enum.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_enum_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_extension.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_file.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_helpers.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_message.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_message_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_primitive_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_service.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_string_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_enum.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_enum_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_extension.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_file.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_helpers.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_message.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_message_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_primitive_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_service.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_string_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/python/protoc.python_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.main.o
obj/third_party/protobuf/libprotobuf_full_do_not_use.a  -Wl,--end-group 
lto1: internal compiler error: in get_alias_symbol, at lto-cgraph.c:921
0x77d283 get_alias_symbol
../../gcc/lto-cgraph.c:921
0x77ff45 input_node
../../gcc/lto-cgraph.c:1012
0x77ff45 input_cgraph_1
../../gcc/lto-cgraph.c:1176
0x77ff45 input_symtab()
../../gcc/lto-cgraph.c:1449
0x507cda read_cgraph_and_symbols
../../gcc/lto/lto.c:2967
0x507cda lto_main()
../../gcc/lto/lto.c:3327
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.
lto-wrapper: g++ returned 1 exit status
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

Dump:
https://docs.google.com/file/d/0B0pisUJ80pO1MWZRMU5MZ3BYWE0/edit?usp=sharing

Thank you,
Martin

[Bug c/57483] New: Linux kernel (lto-3.9 branch) compilation fails with enabled LTO

2013-05-31 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483

Bug ID: 57483
   Summary: Linux kernel (lto-3.9 branch) compilation fails with
enabled LTO
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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 used to be able to compile such kernel, regression was introduced in
revision: 198741

Error:
In function ‘alloc_iommu’:
lto1: internal compiler error: in input_gimple_stmt, at
gimple-streamer-in.c:287
0xc76db5 input_gimple_stmt
../../gcc/gimple-streamer-in.c:286
0xc76db5 input_bb(lto_input_block*, LTO_tags, data_in*, function*, int)
../../gcc/gimple-streamer-in.c:345
0x77d1b3 input_function
../../gcc/lto-streamer-in.c:887
0x77d1b3 lto_read_body
../../gcc/lto-streamer-in.c:1011
0x77d1b3 lto_input_function_body(lto_file_decl_data*, tree_node*, char const*)
../../gcc/lto-streamer-in.c:1055
0x4ff322 lto_materialize_function
../../gcc/lto/lto.c:226
0x4ff322 materialize_cgraph
../../gcc/lto/lto.c:3084
0x506a88 lto_main()
../../gcc/lto/lto.c:3348
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.
make[1]: *** [/tmp/ccRWZATW.ltrans8.ltrans.o] Error 1
make[1]: *** Waiting for unfinished jobs
/tmp/cckatHC0.s: Assembler messages:
/tmp/cckatHC0.s:10068: Error: symbol `__compound_literal.0' is already defined
/tmp/cckatHC0.s:30211: Error: symbol `__compound_literal.0' is already defined
make[1]: *** [/tmp/ccRWZATW.ltrans6.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/home/marxin/gcc-jan/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: lto-wrapper
failed
collect2: error: ld returned 1 exit status
make: *** [vmlinux] Error 1

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-20 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038

--- Comment #23 from Martin Liška marxin.liska at gmail dot com ---
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.

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-13 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038

--- Comment #17 from Martin Liška marxin.liska at gmail dot com ---
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 compiler error: in lto_balanced_map, at lto/lto-partition.c:566
0x52004f lto_balanced_map()
../../gcc/lto/lto-partition.c:566
0x516c0e do_whole_program_analysis
../../gcc/lto/lto.c:3201
0x516c0e lto_main()
../../gcc/lto/lto.c:3341

lto-partition.c:566 refers to the github link

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-13 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038

--- Comment #20 from Martin Liška marxin.liska at gmail dot com ---
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.c:534
0x516c0e do_whole_program_analysis
../../gcc/lto/lto.c:3201
0x516c0e lto_main()
../../gcc/lto/lto.c:3341


https://github.com/marxin/gcc/blob/master/gcc/lto/lto-partition.c#L185-L186

We can either wait for your complex patch or try to debug it.

Martin

[Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]

2013-05-08 Thread marxin.liska at gmail dot com


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: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: marxin.li...@gmail.com





Chromium git repository: May 4, 2013



gcc -v:

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/home/marxin/gcc48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../configure --enable-languages=c,c++,java --enable-bootstrap

--disable-libsanitizer --prefix=/home/marxin/gcc48

Thread model: posix

gcc version 4.8.1 20130505 (prerelease) (GCC) 



failure:

g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC

-Wl,-uIsHeapProfilerRunning,-uProfilerStart

-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22InitialMallocHook_MMapPKvS0_jiiix,-u_Z22InitialMallocHook_SbrkPKvi

-Wl,-u_Z21InitialMallocHook_NewPKvm,-u_Z22InitialMallocHook_MMapPKvS0_miiil,-u_Z22InitialMallocHook_SbrkPKvl

-Wl,-u_ZN15HeapLeakChecker12IgnoreObjectEPKv,-u_ZN15HeapLeakChecker14UnIgnoreObjectEPKv

-Wl,-O1 -Wl,--as-needed -flto=9 -fno-fat-lto-objects -Wl,--gc-sections  -o

out/Release/base_unittests -Wl,--start-group

out/Release/obj.target/base_unittests/base/at_exit_unittest.o

out/Release/obj.target/base_unittests/base/atomicops_unittest.o

out/Release/obj.target/base_unittests/base/base64_unittest.o

out/Release/obj.target/base_unittests/base/bind_helpers_unittest.o

out/Release/obj.target/base_unittests/base/bind_unittest.o

out/Release/obj.target/base_unittests/base/bits_unittest.o

out/Release/obj.target/base_unittests/base/build_time_unittest.o

out/Release/obj.target/base_unittests/base/callback_unittest.o

out/Release/obj.target/base_unittests/base/cancelable_callback_unittest.o

out/Release/obj.target/base_unittests/base/command_line_unittest.o

out/Release/obj.target/base_unittests/base/containers/linked_list_unittest.o

out/Release/obj.target/base_unittests/base/containers/mru_cache_unittest.o

out/Release/obj.target/base_unittests/base/containers/small_map_unittest.o

out/Release/obj.target/base_unittests/base/containers/stack_container_unittest.o

out/Release/obj.target/base_unittests/base/cpu_unittest.o

out/Release/obj.target/base_unittests/base/debug/crash_logging_unittest.o

out/Release/obj.target/base_unittests/base/debug/leak_tracker_unittest.o

out/Release/obj.target/base_unittests/base/debug/stack_trace_unittest.o

out/Release/obj.target/base_unittests/base/debug/trace_event_unittest.o

out/Release/obj.target/base_unittests/base/deferred_sequenced_task_runner_unittest.o

out/Release/obj.target/base_unittests/base/environment_unittest.o

out/Release/obj.target/base_unittests/base/file_util_unittest.o

out/Release/obj.target/base_unittests/base/files/dir_reader_posix_unittest.o

out/Release/obj.target/base_unittests/base/files/file_path_unittest.o

out/Release/obj.target/base_unittests/base/files/file_util_proxy_unittest.o

out/Release/obj.target/base_unittests/base/files/important_file_writer_unittest.o

out/Release/obj.target/base_unittests/base/files/scoped_temp_dir_unittest.o

out/Release/obj.target/base_unittests/base/gmock_unittest.o

out/Release/obj.target/base_unittests/base/guid_unittest.o

out/Release/obj.target/base_unittests/base/hi_res_timer_manager_unittest.o

out/Release/obj.target/base_unittests/base/id_map_unittest.o

out/Release/obj.target/base_unittests/base/i18n/break_iterator_unittest.o

out/Release/obj.target/base_unittests/base/i18n/char_iterator_unittest.o

out/Release/obj.target/base_unittests/base/i18n/case_conversion_unittest.o

out/Release/obj.target/base_unittests/base/i18n/file_util_icu_unittest.o

out/Release/obj.target/base_unittests/base/i18n/icu_string_conversions_unittest.o

out/Release/obj.target/base_unittests/base/i18n/number_formatting_unittest.o

out/Release/obj.target/base_unittests/base/i18n/rtl_unittest.o

out/Release/obj.target/base_unittests/base/i18n/string_search_unittest.o

out/Release/obj.target/base_unittests/base/i18n/time_formatting_unittest.o

out/Release/obj.target/base_unittests/base/json/json_parser_unittest.o

out/Release/obj.target/base_unittests/base/json/json_reader_unittest.o

out/Release/obj.target/base_unittests/base/json/json_value_converter_unittest.o

out/Release/obj.target/base_unittests/base/json/json_value_serializer_unittest.o

out/Release/obj.target/base_unittests/base/json/json_writer_unittest.o

out/Release/obj.target/base_unittests/base/json/string_escape_unittest.o

out/Release/obj.target/base_unittests/base/lazy_instance_unittest.o

out/Release/obj.target/base_unittests/base/logging_unittest.o

out/Release/obj.target/base_unittests/base/md5_unittest.o


[Bug c++/57208] Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]

2013-05-08 Thread marxin.liska at gmail dot com

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

--- Comment #1 from Martin Liška marxin.liska at gmail dot com 2013-05-08 
12:32:24 UTC ---
Created attachment 30054
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30054
Savetemps dump

[Bug c++/57208] Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]

2013-05-08 Thread marxin.liska at gmail dot com

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

--- Comment #2 from Martin Liška marxin.liska at gmail dot com 2013-05-08 
12:32:51 UTC ---
Created attachment 30055
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30055
common.gypi - build configuration

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #3 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
11:20:00 UTC ---
lto-partition.c:265 (add_symbol_to_partition)

c++filt:
std::_Tuple_impl0ul, int const::_Tuple_impl()

dump_symtab_node:
_ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (_ZNSt11_Tuple_implILm0EJRKiEEC1Ev)
@0x7f5a9bc5fab0
  Type: function
  Visibility: prevailing_def_ironly_exp public weak artificial
  References: _ZNSt11_Tuple_implILm0EIRKiEEC1Ev/281155 (alias)
  Referring: 
  Read from file:
/home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/CxxObject/comphelper/source/property/propagg.o
  Availability: overwritable
  Function flags: analyzed finalized alias
  Alias of __comp_ctor  (asm: _ZNSt11_Tuple_implILm0EIRKiEEC1Ev)
  Called by: 
  Calls: 

After iterating on lto-partition.c:274 add_symbol_to_partition_1 is called for
the following node, where assert was reached:

c++filt:

dump_symtab_node:
_ZNSt11_Tuple_implILm0EIRKiEEC1Ev/281155 (__comp_ctor ) @0x7f5a9bc5fbe0
  Type: function
  Visibility: external public visibility_specified
  References: 
  Referring: _ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (alias)
  Read from file:
/home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/CxxObject/comphelper/source/property/propagg.o
  Availability: not_available
  Function flags:
  Called by: 
  Calls: 

Thanks,
Martin

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #5 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
12:43:56 UTC ---
Looks like the problem has many occurrences in CLucene:

_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev/146876
(_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev) @0x2b58d3925be0
  Type: function
  Visibility: prevailing_def_ironly_exp public weak artificial
  References:
_ZNSt11_Tuple_implILm0EIRKPN6lucene5index11IndexReaderEEEC1Ev/146875 (alias)
  Referring: 
  Read from file:
/home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o
  Availability: overwritable
  Function flags: analyzed finalized alias
  Alias of __comp_ctor  (asm:
_ZNSt11_Tuple_implILm0EIRKPN6lucene5index11IndexReaderEEEC1Ev)
  Called by: 
  Calls: 

_ZNSt11_Tuple_implILm0EIRKPN6lucene5index11IndexReaderEEEC1Ev/146875
(__comp_ctor ) @0x2b58d3925d10
  Type: function
  Visibility: external public visibility_specified
  References: 
  Referring:
_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev/146876 (alias)
  Read from file:
/home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o
  Availability: not_available
  Function flags:
  Called by: 
  Calls: 

I've just uploaded preprocessed FieldCacheImpl.c.

Martin

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #6 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
12:44:44 UTC ---
Created attachment 30020
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30020
FieldCacheImpl.c

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #8 from Martin Liška marxin.liska at gmail dot com 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   -DSYSTEM_ZLIB  -Dclucene_shared_EXPORTS
-Dclucene_core_EXPORTS -Dclucene_contribs_lib_EXPORTS   -flto
-fno-fat-lto-objects -fuse-linker-plugin -O2 -DHAVE_GCC_VISIBILITY_FEATURE
-fvisibility=hidden   -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros
-fmessage-length=0 -fno-common -pipe  -fvisibility-inlines-hidden
-DLIBO_MERGELIBS -fPIC -Wshadow -Woverloaded-virtual  -Wnon-virtual-dtor
-std=gnu++0x  -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -O2   -w  -c
$W/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.cpp -o
$W/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o
-MMD -MT
$W/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o
-MP -MF
$W/Dep/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.d_
-I$W/UnpackedTarball/clucene/src/core/CLucene/search/
-I$W/UnpackedTarball/clucene/inc/internal -I$W/UnpackedTarball/clucene/src/core
-I$W/UnpackedTarball/clucene/src/contribs-lib
-I$W/UnpackedTarball/clucene/src/shared  -I$S/include -I$O/inc/external
-I$O/inc  -I/opt/sun-jdk-1.6.0.34/include -I/opt/sun-jdk-1.6.0.34/include/linux
-I$S/config_host mv
$W/Dep/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.d_
$W/Dep/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.d

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #10 from Martin Liška marxin.liska at gmail dot com 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 attach preprocessed propagg.c, hope it will help.

Martin

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #5 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
15:20:17 UTC ---
Created attachment 30024
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30024
Preprocessed propagg.c

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

2013-05-03 Thread marxin.liska at gmail dot com

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

Martin Liška marxin.liska at gmail dot com changed:

   What|Removed |Added

 CC||marxin.liska at gmail dot
   ||com

--- Comment #6 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
15:21:23 UTC ---
(In reply to comment #5)
 Created attachment 30024 [details]
 Preprocessed propagg.c

Sorry for attaching file to wrong bug.

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #11 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
15:22:15 UTC ---
Created attachment 30025
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30025
Preprocessed propag.c

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #13 from Martin Liška marxin.liska at gmail dot com 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?

Thanks,
Martin

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-05-03 Thread marxin.liska at gmail dot com

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

--- Comment #14 from Martin Liška marxin.liska at gmail dot com 2013-05-03 
17:00:19 UTC ---
Created attachment 30027
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30027
Build log1

[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO

2013-04-26 Thread marxin.liska at gmail dot com

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

--- Comment #2 from Martin Liška marxin.liska at gmail dot com 2013-04-26 
09:23:58 UTC ---
So the symbol is really external :

c++filt:
std::_Tuple_impl0ul, int const::_Tuple_impl()

dump_symbol_node:
_ZNSt11_Tuple_implILm0EIRKiEEC1Ev/279814 (__comp_ctor ) @0x7fd6b26766f0
  Type: function
  Visibility: external public visibility_specified
  References: 
  Referring: _ZNSt11_Tuple_implILm0EJRKiEEC1Ev/279815 (alias)
  Read from file:
/home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/CxxObject/comphelper/source/property/propagg.o
  Availability: not_available
  Function flags:
  Called by: 
  Calls:

[Bug c++/57038] New: Latest libreoffice compilation fails with enabled LTO

2013-04-22 Thread marxin.liska at gmail dot com


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: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: marxin.li...@gmail.com





Libreoffice git repository commit:

04a54e7180c2cf9f4855211055ecbc6a41deff56 (Apr 17)



Libreoffice comfigure options:

./autogen.sh --with-parallelism=1 --without-junit --enable-mergelibs

--enable-lto



gcc --version:

gcc (GCC) 4.9.0 20130420 (experimental)



failure:

/usr/bin/make -j 1 -rs -f /home/marxin/Programming/libreoffice/Makefile.gbuild

[build LNK] Library/libcomphelpgcc3.so

lto1: internal compiler error: in add_symbol_to_partition_1, at

lto/lto-partition.c:186

0x5180d5 add_symbol_to_partition_1

../../gcc/lto/lto-partition.c:185

0x51881a lto_balanced_map()

../../gcc/lto/lto-partition.c:532

0x514f3c do_whole_program_analysis

../../gcc/lto/lto.c:3245

0x514f3c lto_main()

../../gcc/lto/lto.c:3385



Command line:

S=/home/marxin/Programming/libreoffice  O=$S/solver/unxlngx6.pro 

W=$S/workdir/unxlngx6.pro   mkdir -p $W/LinkTarget/Library/ 

/usr/bin/ccache g++ -shared -Wl,-z,noexecstack -flto -fuse-linker-plugin -O2  

-Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib'

-Wl,-rpath-link,$O/lib -Wl,-z,defs  -Wl,-rpath-link,/lib:/usr/lib

-Wl,-z,combreloc -L$O/lib  -Wl,--hash-style=gnu  -Wl,--dynamic-list-cpp-new

-Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions  -Wl,-O1 -Wl,-S 

$W/CxxObject/comphelper/source/compare/AnyCompareFactory.o

$W/CxxObject/comphelper/source/container/IndexedPropertyValuesContainer.o

$W/CxxObject/comphelper/source/container/NamedPropertyValuesContainer.o

$W/CxxObject/comphelper/source/container/container.o

$W/CxxObject/comphelper/source/container/containermultiplexer.o

$W/CxxObject/comphelper/source/container/embeddedobjectcontainer.o

$W/CxxObject/comphelper/source/container/enumerablemap.o

$W/CxxObject/comphelper/source/container/enumhelper.o

$W/CxxObject/comphelper/source/container/namecontainer.o

$W/CxxObject/comphelper/source/eventattachermgr/eventattachermgr.o

$W/CxxObject/comphelper/source/misc/accessiblecomponenthelper.o

$W/CxxObject/comphelper/source/misc/accessiblecontexthelper.o

$W/CxxObject/comphelper/source/misc/accessibleeventnotifier.o

$W/CxxObject/comphelper/source/misc/accessiblekeybindinghelper.o

$W/CxxObject/comphelper/source/misc/accessibleselectionhelper.o

$W/CxxObject/comphelper/source/misc/accessibletexthelper.o

$W/CxxObject/comphelper/source/misc/accessiblewrapper.o

$W/CxxObject/comphelper/source/misc/accimplaccess.o

$W/CxxObject/comphelper/source/misc/anytostring.o

$W/CxxObject/comphelper/source/misc/asyncnotification.o

$W/CxxObject/comphelper/source/misc/comphelper_module.o

$W/CxxObject/comphelper/source/misc/comphelper_services.o

$W/CxxObject/comphelper/source/misc/componentbase.o

$W/CxxObject/comphelper/source/misc/componentcontext.o

$W/CxxObject/comphelper/source/misc/componentmodule.o

$W/CxxObject/comphelper/source/misc/configuration.o

$W/CxxObject/comphelper/source/misc/configurationhelper.o

$W/CxxObject/comphelper/source/misc/docpasswordhelper.o

$W/CxxObject/comphelper/source/misc/docpasswordrequest.o

$W/CxxObject/comphelper/source/misc/documentinfo.o

$W/CxxObject/comphelper/source/misc/documentiologring.o

$W/CxxObject/comphelper/source/misc/evtlistenerhlp.o

$W/CxxObject/comphelper/source/misc/evtmethodhelper.o

$W/CxxObject/comphelper/source/misc/ihwrapnofilter.o

$W/CxxObject/comphelper/source/misc/instancelocker.o

$W/CxxObject/comphelper/source/misc/interaction.o

$W/CxxObject/comphelper/source/misc/listenernotification.o

$W/CxxObject/comphelper/source/misc/logging.o

$W/CxxObject/comphelper/source/misc/mediadescriptor.o

$W/CxxObject/comphelper/source/misc/mime^Cnfighelper.o

$W/CxxObject/comphelper/source/misc/namedvaluecollection.o

$W/CxxObject/comphelper/source/misc/numberedcollection.o

$W/CxxObject/comphelper/source/misc/numbers.o

$W/CxxObject/comphelper/source/misc/officeresourcebundle.o

$W/CxxObject/comphelper/source/misc/officerestartmanager.o

$W/CxxObject/comphelper/source/misc/proxyaggregation.o

$W/CxxObject/comphelper/source/misc/scopeguard.o

$W/CxxObject/comphelper/source/misc/SelectionMultiplex.o

$W/CxxObject/comphelper/source/misc/sequenceashashmap.o

$W/CxxObject/comphelper/source/misc/sequence.o

$W/CxxObject/comphelper/source/misc/servicedecl.o

$W/CxxObject/comphelper/source/misc/serviceinfohelper.o

$W/CxxObject/comphelper/source/misc/sharedmutex.o

$W/CxxObject/comphelper/source/misc/stillreadwriteinteraction.o

$W/CxxObject/comphelper/source/misc/anycompare.o

$W/CxxObject/comphelper/source/misc/storagehelper.o

$W/CxxObject/comphelper/source/misc/string.o


[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

2013-03-23 Thread marxin.liska at gmail dot com

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

--- Comment #7 from Martin Liška marxin.liska at gmail dot com 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.

[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

2013-03-23 Thread marxin.liska at gmail dot com

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

Martin Liška marxin.liska at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID

--- Comment #8 from Martin Liška marxin.liska at gmail dot com 2013-03-23 
23:43:36 UTC ---
Invalid bug.

[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

2013-03-12 Thread marxin.liska at gmail dot com

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

--- Comment #6 from Martin Liška marxin.liska at gmail dot com 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 file and version of binutils you used
for build?

Thanks


[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

2013-02-28 Thread marxin.liska at gmail dot com

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

--- Comment #1 from Martin Liška marxin.liska at gmail dot com 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
function ‘_ZN22nsComponentManagerImpl23InitializeStaticModulesEv.part.59’:
/home/marxin/Programming/firefox/xpcom/components/nsComponentManager.cpp:275:0:
internal compiler error: Segmentation fault
 nsComponentManagerImpl::InitializeStaticModules()
 ^
0x85049f crash_signal
../../gcc/toplev.c:332
0x6c0475 can_refer_decl_in_current_unit_p
../../gcc/gimple-fold.c:70
0x6c218a canonicalize_constructor_val(tree_node*, tree_node*)
../../gcc/gimple-fold.c:172
0x6c286c fold_ctor_reference
../../gcc/gimple-fold.c:2944
0x6c6882 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*))
../../gcc/gimple-fold.c:3069
0x6c754c gimple_fold_stmt_to_constant_1(gimple_statement_d*, tree_node*
(*)(tree_node*))
../../gcc/gimple-fold.c:2520
0x992e0d try_to_simplify
../../gcc/tree-ssa-sccvn.c:3257
0x992e0d visit_use
../../gcc/tree-ssa-sccvn.c:3334
0x996e30 process_scc
../../gcc/tree-ssa-sccvn.c:3649
0x996e30 extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:3706
0x996e30 DFS
../../gcc/tree-ssa-sccvn.c:3760
0x996e30 run_scc_vn(vn_lookup_kind)
../../gcc/tree-ssa-sccvn.c:4006
0x97971c do_pre
../../gcc/tree-ssa-pre.c:4700

Thanks


[Bug c++/56312] New: Firefox 20.0a1 compilation with enabled LTO fails

2013-02-13 Thread marxin.liska at gmail dot com


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

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: marxin.li...@gmail.com





Hello,

   I encountered following error with enabled LTO.





error:

/usr/bin/python2.7 /home/marxin/Programming/firefox/js/src/config/pythonpath.py

-I../config /home/marxin/Programming/firefox/js/src/config/expandlibs_exec.py

--depend .deps/js.pp --target js --uselist -- 

/home/marxin/Programming/gcc-mainline/bin/g++ -o js  -pedantic -Wall

-Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits

-Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy

-Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align

-Wno-long-long -flto -fno-rtti -ffunction-sections -fdata-sections

-fno-exceptions -pthread -pipe  -DNDEBUG -DTRIMMED -g -O2 -fomit-frame-pointer

js.o jsoptparse.o jsheaptools.o   -lpthread -flto -Wl,--build-id  

-Wl,-rpath-link,../../../dist/bin

-Wl,-rpath-link,/home/marxin/Programming/firefox/obj-x86_64-unknown-linux-gnu/dist/lib

  -L../../../dist/bin -L../../../dist/lib

-L/home/marxin/Programming/firefox/obj-x86_64-unknown-linux-gnu/dist/lib

-lnspr4 -lplc4 -lplds4 ../editline/libeditline.a ../libjs_static.a

/home/marxin/Programming/firefox/obj-x86_64-unknown-linux-gnu/modules/zlib/src/libmozz.a

-Wl,--whole-archive ../../../dist/lib/libmozglue.a

../../../dist/lib/libmemory.a -Wl,--no-whole-archive -rdynamic -ldl

`PushActiveVMFrame' referenced in section `.text' of

/tmp/ccgCbjBe.ltrans0.ltrans.o: defined in discarded section `.text' of

MethodJIT.o (symbol from plugin)

`PopActiveVMFrame' referenced in section `.text' of

/tmp/ccgCbjBe.ltrans0.ltrans.o: defined in discarded section `.text' of

MethodJIT.o (symbol from plugin)

`js_InternalThrow' referenced in section `.text' of

/tmp/ccgCbjBe.ltrans0.ltrans.o: defined in discarded section `.text' of

InvokeHelpers.o (symbol from plugin)

`PopActiveVMFrame' referenced in section `.text' of

/tmp/ccgCbjBe.ltrans0.ltrans.o: defined in discarded section `.text' of

MethodJIT.o (symbol from plugin)

`js_InternalInterpret' referenced in section `.text' of

/tmp/ccgCbjBe.ltrans0.ltrans.o: defined in discarded section `.text' of

InvokeHelpers.o (symbol from plugin)

`PopActiveVMFrame' referenced in section `.text' of

/tmp/ccgCbjBe.ltrans0.ltrans.o: defined in discarded section `.text' of

MethodJIT.o (symbol from plugin)

collect2: error: ld returned 1 exit status



gcc --version:

g++ (GCC) 4.8.0 20130113 (experimental)



firefox:

changeset:   118351:fc3ed72129d9



.mozconfig:

mk_add_options MOZ_MAKE_FLAGS=-j8

ac_add_options --enable-application=browser

ac_add_options --enable-optimize=-O2

export CC=/home/marxin/Programming/gcc-mainline/bin/gcc

export CXX=/home/marxin/Programming/gcc-mainline/bin/g++



export CFLAGS=-flto

export CXXFLAGS=-flto

export LDFLAGS=-flto



Thank you for your help,

Martin