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

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

[markus at trippelsdorf dot de]

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

            Bug ID: 58733
           Summary: [4.9 Regression] ICE in operator[], at vec.h:827
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: markus at trippelsdorf dot de

testsuite/g++.dg/lto/20090302 ICE's on my machine:

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:827
0x524457 vec<inline_summary, va_gc, vl_embed>::operator[](unsigned int)
        ../../gcc/gcc/vec.h:827
0x524d5c vec<inline_summary, va_gc, vl_embed>::operator[](unsigned int)
        ../../gcc/gcc/lto/lto-partition.c:234
0x524d5c inline_summary
        ../../gcc/gcc/ipa-inline.h:242
0x524d5c add_symbol_to_partition_1
        ../../gcc/gcc/lto/lto-partition.c:206
0x524c0a add_symbol_to_partition_1
        ../../gcc/gcc/lto/lto-partition.c:226
0x524f7b lto_1_to_1_map()
        ../../gcc/gcc/lto/lto-partition.c:357
0x521670 do_whole_program_analysis
        ../../gcc/gcc/lto/lto.c:3078
0x521670 lto_main()
        ../../gcc/gcc/lto/lto.c:3222

Valgrind shows:
==13659== Invalid read of size 4
==13659==    at 0x509679: add_symbol_to_partition_1(ltrans_partition_def*,
symtab_node_def*) (lto-partition.c:206)
==13659==    by 0x5095EA: add_symbol_to_partition_1(ltrans_partition_def*,
symtab_node_def*) (lto-partition.c:226)
==13659==    by 0x5098CF: lto_1_to_1_map() (lto-partition.c:357)
==13659==    by 0x506C41: lto_main() (lto.c:3078)
==13659==    by 0x7B2545: compile_file() (toplev.c:546)
==13659==    by 0x7B40C9: toplev_main(int, char**) (toplev.c:1893)
==13659==    by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so)
==13659==  Address 0x57a0ff0 is not stack'd, malloc'd or (recently) free'd
==13659==

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

[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
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |4.9.0

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

[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

[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 vec<inline_summary, va_gc, vl_embed>::operator[](unsigned int)
        ../../gcc/gcc/vec.h:722
0x52c77c vec<inline_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 vec<inline_summary, va_gc, vl_embed>::operator[](unsigned int)
        ../../gcc/gcc/vec.h:722
0x52d7e8 vec<inline_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

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

[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

[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

[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

[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

[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

[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

[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

[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 vec<inline_summary, va_gc, vl_embed>::operator[](unsigned int)
        ../../gcc/gcc/vec.h:719
0x54cd04 vec<inline_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

[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

[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  <hubicka@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

[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.