[Bug lto/59468] New: ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[Bug lto/59468] New: ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[d.g.gorbachev at gmail dot com]

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

            Bug ID: 59468
           Summary: ICE on invalid C++ code with LTO in
                    gimple_get_virt_method_for_binfo, at
                    gimple-fold.c:3224
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: d.g.gorbachev at gmail dot com

Created attachment 31416
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31416&action=edit
Testcase (compile with `-O2 -flto -shared')

GCC 4.9.0 20131208 (experimental) - r205795.

lto1: internal compiler error: in gimple_get_virt_method_for_binfo, at
gimple-fold.c:3224
0x8408889 gimple_get_virt_method_for_binfo(long long, tree_node*)
    ../../gcc-4.9/gcc/gimple-fold.c:3223
0x845f414 record_target_from_binfo
    ../../gcc-4.9/gcc/ipa-devirt.c:667
0x845f4f2 record_target_from_binfo
    ../../gcc-4.9/gcc/ipa-devirt.c:684
0x845f4f2 record_target_from_binfo
    ../../gcc-4.9/gcc/ipa-devirt.c:684
0x845f609 possible_polymorphic_call_targets_1
    ../../gcc-4.9/gcc/ipa-devirt.c:708
0x845f670 possible_polymorphic_call_targets_1
    ../../gcc-4.9/gcc/ipa-devirt.c:714
0x8460e0f possible_polymorphic_call_targets(tree_node*, long long,
ipa_polymorphic_call_context, bool*, void**)
    ../../gcc-4.9/gcc/ipa-devirt.c:1295
0x8265d1d possible_polymorphic_call_targets(cgraph_edge*, bool*, void**)
    ../../gcc-4.9/gcc/ipa-utils.h:114
0x848cd5d walk_polymorphic_call_targets
    ../../gcc-4.9/gcc/ipa.c:174
0x848d40a symtab_remove_unreachable_nodes(bool, _IO_FILE*)
    ../../gcc-4.9/gcc/ipa.c:397
0x8578656 execute_todo
    ../../gcc-4.9/gcc/passes.c:1884

Some older 4.9.0 builds give a message like "lto1: fatal error: LTO_tags out of
range: Range is 0 to 353, value is 356". Other builds, such as 4.9.0 20131027
(r204109) crash with:

lto1: internal compiler error: Segmentation fault
0x85c19c0 crash_signal
    ../../gcc-4.9/gcc/toplev.c:334
0x84953be lto_file_decl_data_get_var_decl
    ../../gcc-4.9/gcc/lto-streamer.h:1190
0x84953be lto_input_tree_ref(lto_input_block*, data_in*, function*, LTO_tags)
    ../../gcc-4.9/gcc/lto-streamer-in.c:244
0x849553a lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
    ../../gcc-4.9/gcc/lto-streamer-in.c:1242
0x81403ae lto_read_decls
    ../../gcc-4.9/gcc/lto/lto.c:1914
0x8140726 lto_file_finalize
    ../../gcc-4.9/gcc/lto/lto.c:2167
0x8140764 lto_create_files_from_ids
    ../../gcc-4.9/gcc/lto/lto.c:2177
0x8140822 lto_file_read
    ../../gcc-4.9/gcc/lto/lto.c:2217
0x8140b51 read_cgraph_and_symbols
    ../../gcc-4.9/gcc/lto/lto.c:2823
0x81410c9 lto_main()
    ../../gcc-4.9/gcc/lto/lto.c:3254

With GCC 4.7.4:

In file included from 1.C:25:0,
                 from :12:
2.C:15:8: warning: type of '_ZTV1S' does not match original declaration
[enabled by default]
In file included from :8:0:
1.C:15:8: note: previously declared here
In file included from 1.C:25:0,
                 from :12:
2.C:6:8: warning: type of '_ZTV1X' does not match original declaration [enabled
by default]
In file included from :4:0:
1.C:6:8: note: previously declared here

There are no errors or warnings with GCC 4.8.3.

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-11
   Target Milestone|---                         |4.9.0
            Summary|ICE on invalid C++ code     |[4.9 Regression] ICE on
                   |with LTO in                 |invalid C++ code with LTO
                   |gimple_get_virt_method_for_ |in
                   |binfo, at                   |gimple_get_virt_method_for_
                   |gimple-fold.c:3224          |binfo, at
                   |                            |gimple-fold.c:3224
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
works with 4.8.

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have

(int (*__vtbl_ptr_type) ()) &_ZTI1S

at this point:

3219      fn = fold_ctor_reference (TREE_TYPE (TREE_TYPE (v)), init,
3220                    offset, size, v);
3221      if (!fn || integer_zerop (fn))
3222        return NULL_TREE;
3223      gcc_assert (TREE_CODE (fn) == ADDR_EXPR
3224              || TREE_CODE (fn) == FDESC_EXPR);

(gdb) p v
$2 = <var_decl 0x7ffff6d77c78 _ZTV1S>

The vtable layout does not match (so we have a ODR violation here).  It
would be helpful to not ICE and maybe diagnose this.

Not ICEing is simple by giving up instead of asserting in
gimple_get_virt_method_for_binfo.

We shouldn't merge any of the non-matching vtables though and thus not the
types either.  So I'm not yet sure how the "wrong" type can end up here.

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[d.g.gorbachev at gmail dot com]

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

--- Comment #3 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> ---
> works with 4.8.

Perhaps it should be counted as a 4.8 regression - 4.7 warns about the
non-matching vtables.

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We do very basic ODR check in ipa-devirt, perhaps we can extend it to handle
this case, too.

But as a fallback we should probably also stop ICEing when things progress to
actual fold (I saw ICEs like this before but they all tracked down to bugs in
devirtualization logic, this is first one that really come from misformed
source code).

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[d.g.gorbachev at gmail dot com]

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

--- Comment #7 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> ---
Are such strange testcases useful for you? Should I file another bug report for
this new TC?

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Both strange and non-invalid testcases are welcome.  A lot has changed in IPA
in 4.9 and I definitely have to chase out bugs in side cases.

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[d.g.gorbachev at gmail dot com]

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

--- Comment #10 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> ---
I confirm that there is no ICE with the 1st testcase. The 2nd still causes ICE
in function_and_variable_visibility, at ipa.c:1000.

(Something strange happened with the 2nd attachment. I filed another PR 60150
with re-attached testcase.)

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Tue Feb 11 22:54:21 2014
New Revision: 207702

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

    PR lto/59468
    * ipa-utils.h (possible_polymorphic_call_targets): Update prototype
    and wrapper.
    * ipa-devirt.c: Include demangle.h
    (odr_violation_reported): New static variable.
    (add_type_duplicate): Update odr_violations.
    (maybe_record_node): Add completep parameter; update it.
    (record_target_from_binfo): Add COMPLETEP parameter;
    update it as needed.
    (possible_polymorphic_call_targets_1): Likewise.
    (struct polymorphic_call_target_d): Add nonconstruction_targets;
    rename FINAL to COMPLETE.
    (record_targets_from_bases): Sanity check we found the binfo;
    fix COMPLETEP updating.
    (possible_polymorphic_call_targets): Add NONCONSTRUTION_TARGETSP
    parameter, fix computing of COMPLETEP.
    (dump_possible_polymorphic_call_targets): Imrove readability of dump; at
    LTO time do demangling.
    (ipa_devirt): Use nonconstruction_targets; Improve dumps.
    * gimple-fold.c (gimple_get_virt_method_for_vtable): Add can_refer
    parameter.
    (gimple_get_virt_method_for_binfo): Likewise.
    * gimple-fold.h (gimple_get_virt_method_for_binfo,
    gimple_get_virt_method_for_vtable): Update prototypes.

    PR lto/59468
    * g++.dg/ipa/devirt-27.C: New testcase.
    * g++.dg/ipa/devirt-26.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/ipa/devirt-26.C
    trunk/gcc/testsuite/g++.dg/ipa/devirt-27.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/decl2.c
    trunk/gcc/gimple-fold.c
    trunk/gcc/gimple-fold.h
    trunk/gcc/ipa-devirt.c
    trunk/gcc/ipa-utils.h
    trunk/gcc/testsuite/ChangeLog

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to be fixed now.  Please reopen if there is some reason you wanted to
keep this open.