Bug 85391 - [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887
Summary: [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 8.0.1
: P1 normal
Target Milestone: 8.0
Assignee: Jan Hubicka
URL:
Keywords: ice-on-valid-code, needs-reduction
Depends on:
Blocks:
 
Reported: 2018-04-13 08:47 UTC by Martin Liška
Modified: 2018-04-18 20:10 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-04-13 00:00:00


Attachments
test-case (705.71 KB, application/x-xz)
2018-04-15 08:57 UTC, Martin Liška
Details
test-case (595.00 KB, application/x-xz)
2018-04-15 08:59 UTC, Martin Liška
Details
test-case (672.39 KB, application/x-xz)
2018-04-15 09:00 UTC, Martin Liška
Details
test-case (638.90 KB, application/x-xz)
2018-04-15 09:03 UTC, Martin Liška
Details
test-case (824.59 KB, application/x-xz)
2018-04-15 09:05 UTC, Martin Liška
Details
test-case (707.36 KB, application/x-xz)
2018-04-15 09:09 UTC, Martin Liška
Details
Proposed fix (632 bytes, patch)
2018-04-16 14:05 UTC, Jan Hubicka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2018-04-13 08:47:29 UTC
Happens during build of libreoffice:

$ lto1: internal compiler error: in add_type_duplicate, at ipa-devirt.c:1887
0xaccb4b add_type_duplicate
	../../gcc/ipa-devirt.c:1887
0xacd11b get_odr_type(tree_node*, bool)
	../../gcc/ipa-devirt.c:2040
0xac6994 odr_subtypes_equivalent_p
	../../gcc/ipa-devirt.c:695
0xac9c2f odr_types_equivalent_p
	../../gcc/ipa-devirt.c:1385
0xac6b5a odr_subtypes_equivalent_p
	../../gcc/ipa-devirt.c:716
0xacac6d odr_types_equivalent_p
	../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
	../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
	../../gcc/ipa-devirt.c:2040
0xac69b0 odr_subtypes_equivalent_p
	../../gcc/ipa-devirt.c:696
0xacac6d odr_types_equivalent_p
	../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
	../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
	../../gcc/ipa-devirt.c:2040
0xac69b0 odr_subtypes_equivalent_p
	../../gcc/ipa-devirt.c:696
0xacac6d odr_types_equivalent_p
	../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
	../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
	../../gcc/ipa-devirt.c:2040
0xac69b0 odr_subtypes_equivalent_p
	../../gcc/ipa-devirt.c:696
0xacac6d odr_types_equivalent_p
	../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
	../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
	../../gcc/ipa-devirt.c:2040
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [/tmp/ccKp93tD.mk:74: /tmp/cczeeOnm.ltrans24.ltrans.o] Error 1
Comment 1 Martin Liška 2018-04-13 09:11:04 UTC
With following debug patch:

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index fa9380cce80..7d14a923b4d 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1869,7 +1869,7 @@ add_type_duplicate (odr_type val, tree type)
     }
   gcc_assert (val->odr_violated || !odr_must_violate);
   /* Sanity check that all bases will be build same way again.  */
-  if (flag_checking
+  if (true//flag_checking
       && COMPLETE_TYPE_P (type) && COMPLETE_TYPE_P (val->type)
       && TREE_CODE (val->type) == RECORD_TYPE
       && TREE_CODE (type) == RECORD_TYPE
@@ -1884,7 +1884,23 @@ add_type_duplicate (odr_type val, tree type)
        if (polymorphic_type_binfo_p (BINFO_BASE_BINFO
                                         (TYPE_BINFO (type), i)))
          num_poly_bases++;
+
+      if (num_poly_bases != val->bases.length ())
+      {
+       fprintf(stderr, "poly bases: %d\n", num_poly_bases);
+       for (i = 0; i < BINFO_N_BASE_BINFOS (TYPE_BINFO (type)); i++)
+         if (polymorphic_type_binfo_p (BINFO_BASE_BINFO
+                                          (TYPE_BINFO (type), i)))
+           debug_tree(BINFO_BASE_BINFO (TYPE_BINFO (type), i));
+       fprintf(stderr, "val bases: %d\n", val->bases.length ());
+
+       for (unsigned i = 0; i < val->bases.length (); i++)
+           debug_tree(val->bases[i]->type);
+      }
+
+
       gcc_assert (num_poly_bases == val->bases.length ());
+
       for (j = 0, i = 0; i < BINFO_N_BASE_BINFOS (TYPE_BINFO (type));
           i++)
        if (polymorphic_type_binfo_p (BINFO_BASE_BINFO

I see:

poly bases: 2
 <tree_binfo 0x7ffff52aad00
    type <record_type 0x7ffff5666b28 SfxViewShell addressable needs-constructing BLK
        size <integer_cst 0x7ffff5dd4030 constant 1344>
        unit-size <integer_cst 0x7ffff5dd4060 constant 168>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff5871690
        attributes <tree_list 0x7ffff5d36618
            purpose <identifier_node 0x7ffff5d365f0 visibility>
            value <tree_list 0x7ffff5d365c8
                value <string_cst 0x7ffff69978e0 type <array_type 0x7ffff5d375e8>
                    readonly constant static "default\000">>>
        fields <field_decl 0x7ffff566d390 D.42120 type <record_type 0x7ffff5efc690 SfxShell>
            ignored BLK /home/marxin/BIG/Programming/libreoffice/include/sfx2/viewsh.hxx:145:22
            size <integer_cst 0x7ffff687a1b0 constant 320>
            unit-size <integer_cst 0x7ffff6994810 constant 40>
            align:64 warn_if_not_align:0 offset_align 128
            offset <integer_cst 0x7ffff67a7c18 constant 0>
            bit-offset <integer_cst 0x7ffff67a7c60 constant 0> context <record_type 0x7ffff5666b28 SfxViewShell> chain <field_decl 0x7ffff566d2f8 D.42119>> context <translation_unit_decl 0x7ffff58778e8 /home/marxin/BIG/Programming/libreoffice/sc/source/ui/docshell/olinefun.cxx>
        chain <type_decl 0x7ffff566d428 SfxViewShell>>
    bases:4 offset <integer_cst 0x7ffff67a7c18 0>>
 <tree_binfo 0x7ffff5355f08
    type <record_type 0x7ffff56fb5e8 ScDBFunc addressable needs-constructing BLK
        size <integer_cst 0x7ffff5b2af30 constant 8128>
        unit-size <integer_cst 0x7ffff5bc8708 constant 1016>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff56fb5e8
        fields <field_decl 0x7ffff5382720 _vptr.ScDBFunc type <pointer_type 0x7ffff69a0930>
            unsigned virtual DI /home/marxin/BIG/Programming/libreoffice/sc/source/ui/inc/dbfunc.hxx:39:0
            size <integer_cst 0x7ffff67a7be8 constant 64>
            unit-size <integer_cst 0x7ffff67a7c00 constant 8>
            align:64 warn_if_not_align:0 offset_align 128
            offset <integer_cst 0x7ffff67a7c18 constant 0>
            bit-offset <integer_cst 0x7ffff67a7c60 constant 0> context <record_type 0x7ffff56fb5e8 ScDBFunc> chain <field_decl 0x7ffff53827b8 D.52057>> context <translation_unit_decl 0x7ffff5545d98 /home/marxin/BIG/Programming/libreoffice/sc/source/ui/view/dbfunc.cxx>
        chain <type_decl 0x7ffff5382850 ScDBFunc>>
    bases:1 offset <integer_cst 0x7ffff5dd4060 168>>
val bases: 1
 <record_type 0x7ffff5871690 SfxViewShell addressable needs-constructing BLK
    size <integer_cst 0x7ffff5dd4030 type <integer_type 0x7ffff67bb0a8 bitsizetype> constant 1344>
    unit-size <integer_cst 0x7ffff5dd4060 type <integer_type 0x7ffff67bb000 sizetype> constant 168>
    align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff5871690
    attributes <tree_list 0x7ffff5d36618
        purpose <identifier_node 0x7ffff5d365f0 visibility>
        value <tree_list 0x7ffff5d365c8
            value <string_cst 0x7ffff69978e0 type <array_type 0x7ffff5d375e8>
                readonly constant static "default\000">>>
    fields <field_decl 0x7ffff5873688 D.33082
        type <record_type 0x7ffff5efc690 SfxShell addressable needs-constructing BLK
            size <integer_cst 0x7ffff687a1b0 constant 320>
            unit-size <integer_cst 0x7ffff6994810 constant 40>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff5d490a8 attributes <tree_list 0x7ffff5d36618> fields <field_decl 0x7ffff5efd5f0 D.10874> context <translation_unit_decl 0x7ffff67b1c30 /home/marxin/BIG/Programming/libreoffice/sc/source/core/tool/detfunc.cxx>
            chain <type_decl 0x7ffff5efd688 SfxShell>>
        ignored BLK /home/marxin/BIG/Programming/libreoffice/include/sfx2/viewsh.hxx:145:22 size <integer_cst 0x7ffff687a1b0 320> unit-size <integer_cst 0x7ffff6994810 40>
        align:64 warn_if_not_align:0 offset_align 128
        offset <integer_cst 0x7ffff67a7c18 constant 0>
        bit-offset <integer_cst 0x7ffff67a7c60 constant 0> context <record_type 0x7ffff5871690 SfxViewShell>
        chain <field_decl 0x7ffff58735f0 D.33081 type <record_type 0x7ffff5d37690 SfxListener>
            ignored BLK /home/marxin/BIG/Programming/libreoffice/include/sfx2/viewsh.hxx:145:22
            size <integer_cst 0x7ffff67a7c30 constant 128>
            unit-size <integer_cst 0x7ffff67a7c48 constant 16>
            align:64 warn_if_not_align:0 offset_align 128
            offset <integer_cst 0x7ffff67c3048 constant 32>
            bit-offset <integer_cst 0x7ffff67a7be8 constant 64> context <record_type 0x7ffff5871690 SfxViewShell> chain <field_decl 0x7ffff5873558 D.33080>>> context <translation_unit_decl 0x7ffff5e6cca8 /home/marxin/BIG/Programming/libreoffice/sc/source/ui/Accessibility/AccessibleCell.cxx>
    chain <type_decl 0x7ffff5873720 SfxViewShell>>
Comment 2 Martin Liška 2018-04-13 09:51:46 UTC
Ok so I have 6 pre-processed source files having in total ~40MB. Hope I can reduce that.
Comment 3 Martin Liška 2018-04-13 10:34:56 UTC
Started with r258481.
Comment 4 Eric Botcazou 2018-04-13 16:26:01 UTC
Let's just back out my couple of patches to ipa-devirt.c.  Nobody seems to care about PR ipa/83983 so I guess I no longer do either.
Comment 5 Martin Liška 2018-04-14 06:39:11 UTC
(In reply to Eric Botcazou from comment #4)
> Let's just back out my couple of patches to ipa-devirt.c.  Nobody seems to
> care about PR ipa/83983 so I guess I no longer do either.

Sorry for overlooking the PR83983, I can help you with that next week.
Now I've got reduced 1/6 of preprocessed files. Hope that having a reasonable small test-case would allow you do debug that and fix?
Comment 6 Eric Botcazou 2018-04-14 09:55:12 UTC
> Sorry for overlooking the PR83983, I can help you with that next week.
> Now I've got reduced 1/6 of preprocessed files. Hope that having a
> reasonable small test-case would allow you do debug that and fix?

No, sorry, I'm giving up, just revert my couple of changes instead.
Comment 7 Martin Liška 2018-04-15 08:57:39 UTC
Created attachment 43932 [details]
test-case
Comment 8 Martin Liška 2018-04-15 08:59:40 UTC
Created attachment 43934 [details]
test-case
Comment 9 Martin Liška 2018-04-15 09:00:52 UTC
Created attachment 43935 [details]
test-case
Comment 10 Martin Liška 2018-04-15 09:03:47 UTC
Created attachment 43936 [details]
test-case
Comment 11 Martin Liška 2018-04-15 09:05:09 UTC
Created attachment 43937 [details]
test-case
Comment 12 Martin Liška 2018-04-15 09:09:10 UTC
Created attachment 43938 [details]
test-case
Comment 13 Martin Liška 2018-04-15 09:11:17 UTC
I'm uploading test-cases. Unfortunately during reduction I diverged to PR85405.
Comment 14 Jan Hubicka 2018-04-16 14:05:59 UTC
Created attachment 43947 [details]
Proposed fix

We looked into this with Maritn todday. There are two bugs: one is the fact that lto.c forgets to register the type in case it was within strongly connected component after its outer type. The order depends on hash values and is not well determined. We do not want to test TYPE_CANONICAL being non-NULL. Martin is testing it.

Other is the fact that Eric's last change make odr types compatible when one of them is incomplete. This is not necessarily the case. The patch should fix the ordering issue by going the slow path in case type already in hashtable is incomplete. In this case it won't take long to compare it with the other type anyway.
Comment 15 Eric Botcazou 2018-04-16 18:38:10 UTC
> We looked into this with Martin todday. There are two bugs: one is the fact
> that lto.c forgets to register the type in case it was within strongly
> connected component after its outer type. The order depends on hash values
> and is not well determined. We do not want to test TYPE_CANONICAL being
> non-NULL. Martin is testing it.

OK, thanks for sorting this out.  It helps when specialists kick in. ;-)
Comment 16 Martin Liška 2018-04-17 11:59:52 UTC
(In reply to Jan Hubicka from comment #14)
> Created attachment 43947 [details]
> Proposed fix
> 
> We looked into this with Maritn todday. There are two bugs: one is the fact
> that lto.c forgets to register the type in case it was within strongly
> connected component after its outer type. The order depends on hash values
> and is not well determined. We do not want to test TYPE_CANONICAL being
> non-NULL. Martin is testing it.
> 
> Other is the fact that Eric's last change make odr types compatible when one
> of them is incomplete. This is not necessarily the case. The patch should
> fix the ordering issue by going the slow path in case type already in
> hashtable is incomplete. In this case it won't take long to compare it with
> the other type anyway.

Unfortunately with the suggested patch I see the same ICE for same types as seen in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85391#c1

Minimal test-case this time is 12 files, would take a really long time to reduce.
Comment 17 Jan Hubicka 2018-04-18 11:29:57 UTC
Author: hubicka
Date: Wed Apr 18 11:29:26 2018
New Revision: 259464

URL: https://gcc.gnu.org/viewcvs?rev=259464&root=gcc&view=rev
Log:

	PR lto/85391
	* lto.c (lto_read_decls): Do not test TYPE_CANONICAL before registering odr
	types.
	* g++.dg/lto/pr83121_0.C: Update template.
	* g++.dg/lto/pr83121_1.C: Update template.
	* g++.dg/lto/pr84805_0.C: Update template.
	* g++.dg/lto/pr84805_1.C: Update template.
	* g++.dg/lto/pr84805_2.C: Update template.

Modified:
    trunk/gcc/lto/ChangeLog
    trunk/gcc/lto/lto.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/lto/pr83121_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr83121_1.C
    trunk/gcc/testsuite/g++.dg/lto/pr84805_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr84805_1.C
    trunk/gcc/testsuite/g++.dg/lto/pr84805_2.C
Comment 18 Martin Liška 2018-04-18 20:09:16 UTC
Author: marxin
Date: Wed Apr 18 20:08:44 2018
New Revision: 259479

URL: https://gcc.gnu.org/viewcvs?rev=259479&root=gcc&view=rev
Log:
Make Wodr warnings stable.

2018-04-18  Martin Liska  <mliska@suse.cz>

	PR ipa/83983
	PR ipa/85391
	* lto.c (cmp_type_location): New function.
	(lto_read_decls): First collect all types, then
	sort them according by location before register_odr_type
	is called.
2018-04-18  Martin Liska  <mliska@suse.cz>

	PR ipa/83983
	PR ipa/85391
	* g++.dg/lto/pr83121_1.C (struct Environment): Adjust expected
	output.

Modified:
    trunk/gcc/lto/ChangeLog
    trunk/gcc/lto/lto.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/lto/pr83121_1.C
Comment 19 Martin Liška 2018-04-18 20:10:01 UTC
Fixed.