[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2014-03-02 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org ---
I no longer get the ICE that I think was caused by an alias. The mixup in
between PREVAILING_DEF/PREVAILING_DEF_ORONLY_EXP however ought to be fixed on
gold side.
Can you, please, verify that the ICE is gone and fill in gold PR?

This would lead to rather important missed optimizations.


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2014-03-02 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org ---
Forgot to mention, I think the ICE is solved by the following patch:

2014-02-14  Jan Hubicka  hubi...@ucw.cz

* lto-partition.c (add_symbol_to_partition_1,
undo_partition, lto_balanced_map): Aliases have no
defined size.
(lto_balanced_map): Do not follow refering variables
if they can be optimized out.

the ICE however happens because we fail to optimize out the dead code because
gold us it is used by non-LTO object file in the same DSO. This is clear bug.


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2014-03-02 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
URL||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=16650
 Resolution|--- |FIXED

--- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
https://sourceware.org/bugzilla/show_bug.cgi?id=16650

I can confirm that the ICE is gone.


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2014-01-18 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
With gold I get:

markus@x4 lto % cat 20090302_0.C
/* { dg-lto-do link } */
/* { dg-require-effective-target fpic } */
/* { dg-lto-options {{-fPIC -flto -flto-partition=1to1 -r -nostdlib}} } */
struct Foo {
  bool Mumble();
  static void Bar() { if (foo_-Mumble()) foo_ = 0; }
  static void Baz() { Bar(); }
  static Foo *foo_;
};
void Unused() { Foo::Bar(); Foo::Baz(); }

markus@x4 lto % g++ -fPIC -flto -r -nostdlib 20090302_0.C
lto1: internal compiler error: in operator[], at vec.h:719
0x54b227 vecinline_summary, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/vec.h:719
0x54cd04 vecinline_summary, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/vec.h:1167
0x54cd04 inline_summary
../../gcc/gcc/ipa-inline.h:244
0x54cd04 lto_balanced_map()
../../gcc/gcc/lto/lto-partition.c:502
0x547d76 do_whole_program_analysis
../../gcc/gcc/lto/lto.c:3161
0x547d76 lto_main()
../../gcc/gcc/lto/lto.c:3301

markus@x4 lto % cat 20090302_0.res
1
20090302_0.o 5
181 afeebb30522d796 PREVAILING_DEF _ZN3Foo3BarEv
184 afeebb30522d796 PREVAILING_DEF _ZN3Foo3BazEv
187 afeebb30522d796 PREVAILING_DEF _Z6Unusedv
203 afeebb30522d796 UNDEF _ZN3Foo4foo_E
200 afeebb30522d796 UNDEF _ZN3Foo6MumbleEv

_ZN3Foo3BazEv/1 (Baz) @0x7f5f7ba71000
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def public weak comdat
comdat_group:_ZN3Foo3BazEv one_only
  References: 
  Referring: _ZN3Foo3BazEv.localalias.0/7 (alias)


With bfd the symbols are PREVAILING_DEF_IRONLY_EXP:

markus@x4 foo % cat 20090302_0.res
1
20090302_0.o 5
181 8c3642f7b0939cf4 PREVAILING_DEF_IRONLY_EXP _ZN3Foo3BarEv
184 8c3642f7b0939cf4 PREVAILING_DEF_IRONLY_EXP _ZN3Foo3BazEv
187 8c3642f7b0939cf4 PREVAILING_DEF_IRONLY_EXP _Z6Unusedv
203 8c3642f7b0939cf4 UNDEF _ZN3Foo4foo_E
200 8c3642f7b0939cf4 UNDEF _ZN3Foo6MumbleEv
markus@x4 foo % 

_ZN3Foo3BazEv/1 (Baz) @0x7f5166ec1000
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
  References: 
  Referring:


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2014-01-16 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 lto % /var/tmp/gcc_valgrind/usr/local/bin/g++ -fPIC -flto -r
-nostdlib 20081118_0.C 20081118_1.C
==12420== Conditional jump or move depends on uninitialised value(s)
==12420==at 0x535652: lto_balanced_map() (lto-partition.c:705)
==12420==by 0x531B0D: lto_main() (lto.c:3161)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420==  Uninitialised value was created by a client request
==12420==at 0x53736B: ggc_internal_alloc_stat(unsigned long)
(ggc-page.c:1339)
==12420==by 0x674E6F: ggc_realloc_stat(void*, unsigned long)
(ggc-common.c:192)
==12420==by 0x6B38B2: inline_summary_alloc() (vec.h:384)
==12420==by 0x6BF365: inline_read_summary() (ipa-inline-analysis.c:3996)
==12420==by 0x767701: ipa_read_summaries_1(opt_pass*) (passes.c:2519)
==12420==by 0x5303A7: lto_main() (lto.c:2963)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420== 
==12420== Conditional jump or move depends on uninitialised value(s)
==12420==at 0x535734: lto_balanced_map() (lto-partition.c:726)
==12420==by 0x531B0D: lto_main() (lto.c:3161)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420==  Uninitialised value was created by a client request
==12420==at 0x53736B: ggc_internal_alloc_stat(unsigned long)
(ggc-page.c:1339)
==12420==by 0x674E6F: ggc_realloc_stat(void*, unsigned long)
(ggc-common.c:192)
==12420==by 0x6B38B2: inline_summary_alloc() (vec.h:384)
==12420==by 0x6BF365: inline_read_summary() (ipa-inline-analysis.c:3996)
==12420==by 0x767701: ipa_read_summaries_1(opt_pass*) (passes.c:2519)
==12420==by 0x5303A7: lto_main() (lto.c:2963)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420==


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-12-04 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, with r205392 now in, can this still be reproduced?


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-12-04 Thread octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #8 from Markus Trippelsdorf octoploid at yandex dot com ---
(In reply to Jakub Jelinek from comment #7)
 So, with r205392 now in, can this still be reproduced?

Unfortunately, yes.


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-11-22 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||lto
   Priority|P3  |P1
 CC||hjl.tools at gmail dot com

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Seems like -fuse-ld=gold doesn't work with -flto, so not yet confirmed.

./xgcc -B. t.c t2.c -flto -fuse-ld=gold
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: -f
may not be used without -shared
collect2: error: ld returned 1 exit status

it invokes collect.ld for me when doing

make check-g++ RUNTESTFLAGS=--target_board=unix/-fuse-ld=gold
lto.exp=20090302_0.C

with an installed compiler -fuse-ld=gold works.  It would be nice if
running the testsuite with an alternate linker would work - HJ, can you
try investigating this?


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-11-22 Thread octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #5 from Markus Trippelsdorf octoploid at yandex dot com ---
FYI I'm running the latest binutils trunk:
 GNU gold (GNU Binutils 2.24.51.20131121) 1.11

(I don't use -fuse-ld=gold normally, because one can
easily switch linkers globally, e.g.:
ln -f /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld.gold 
/usr/x86_64-pc-linux-gnu/binutils-bin/git/ld)


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-11-22 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Richard Biener from comment #4)
 Seems like -fuse-ld=gold doesn't work with -flto, so not yet confirmed.
 
 with an installed compiler -fuse-ld=gold works.  It would be nice if
 running the testsuite with an alternate linker would work - HJ, can you
 try investigating this?

A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02870.html


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-11-06 Thread octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

--- Comment #3 from octoploid at yandex dot com ---
The issue only happens when I use the 'gold' linker,
ld.bfd is fine. So maybe a binutils bug?
Honza?


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-11-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Seems to work now.


[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

2013-11-05 Thread octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

octoploid at yandex dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |---

--- Comment #2 from octoploid at yandex dot com ---
Hmm, not for me unfortunately:

markus@x4 lto % cd /var/tmp/gcc/gcc/testsuite/g++.dg/lto

markus@x4 lto % g++ -fPIC -flto -flto-partition=1to1 -r -nostdlib 20090302_0.C
20090302_1.C
lto1: internal compiler error: in operator[], at vec.h:722
0x52bd87 vecinline_summary, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/vec.h:722
0x52c77c vecinline_summary, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/lto/lto-partition.c:235
0x52c77c inline_summary
../../gcc/gcc/ipa-inline.h:242
0x52c77c add_symbol_to_partition_1
../../gcc/gcc/lto/lto-partition.c:207
0x52c62b add_symbol_to_partition_1
../../gcc/gcc/lto/lto-partition.c:227
0x52c9cb lto_1_to_1_map()
../../gcc/gcc/lto/lto-partition.c:358
0x528856 do_whole_program_analysis
../../gcc/gcc/lto/lto.c:3120
0x528856 lto_main()
../../gcc/gcc/lto/lto.c:3264
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: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit status
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

markus@x4 lto % g++ -fPIC -flto -r -nostdlib 20081118_0.C 20081118_1.C
lto1: internal compiler error: in operator[], at vec.h:722
0x52bd87 vecinline_summary, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/vec.h:722
0x52d7e8 vecinline_summary, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/lto/lto-partition.c:570
0x52d7e8 inline_summary
../../gcc/gcc/ipa-inline.h:242
0x52d7e8 lto_balanced_map()
../../gcc/gcc/lto/lto-partition.c:475
0x52884c do_whole_program_analysis
../../gcc/gcc/lto/lto.c:3124
0x52884c lto_main()
../../gcc/gcc/lto/lto.c:3264
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: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit status
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status