[Bug lto/54898] [4.8 regression] ICE in uniquify_nodes, at lto/lto.c:1898

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Oct 11 15:16:00 GMT 2012


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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-11 15:16:07 UTC ---
We produce this situation somewhen during WPA stage (probably type merging).

(gdb) p expr
$1 = (tree) 0x7ffff693e3f0
(gdb) p expr->type_common.main_variant
$2 = (tree) 0x7ffff6922b28

type merging assumes that if TYPE_MAIN_VARIANT (t) == t then t will
prevail or be replaced with a different type that also is a main variant.

we first read $2, with main variant 0x7ffff67f05e8:

(gdb) call debug_tree ($2)
 <integer_type 0x7ffff6922b28 wchar_t SI
    size <integer_cst 0x7ffff67f40a0 type <integer_type 0x7ffff67f00a8
bitsizetype> constant 32>
    unit size <integer_cst 0x7ffff67f40c0 type <integer_type 0x7ffff67f0000
sizetype> constant 4>
    align 32 symtab 0 alias set -1 structural equality precision 32 min
<integer_cst 0x7ffff67f4040 -2147483648> max <integer_cst 0x7ffff67f4060
2147483647> context <translation_unit_decl 0x7ffff67fbf18 D.2366>>
(gdb) call debug_tree ($10)
 <integer_type 0x7ffff67f05e8 int public SI
    size <integer_cst 0x7ffff67f40a0 type <integer_type 0x7ffff67f00a8
bitsizetype> constant 32>
    unit size <integer_cst 0x7ffff67f40c0 type <integer_type 0x7ffff67f0000
sizetype> constant 4>
    align 32 symtab 0 alias set -1 canonical type 0x7ffff67f05e8 precision 32
min <integer_cst 0x7ffff67f4040 -2147483648> max <integer_cst 0x7ffff67f4060
2147483647>
    pointer_to_this <pointer_type 0x7ffff67f82a0>>

then we read $1

(gdb) call debug_tree ($1)
 <integer_type 0x7ffff693e3f0 SI
    size <integer_cst 0x7ffff67f40a0 type <integer_type 0x7ffff67f00a8
bitsizetype> constant 32>
    unit size <integer_cst 0x7ffff67f40c0 type <integer_type 0x7ffff67f0000
sizetype> constant 4>
    align 32 symtab 0 alias set -1 structural equality precision 32 min
<integer_cst 0x7ffff6912a20 -2147483648> max <integer_cst 0x7ffff6912a40
2147483647>>
(gdb) call debug_tree ($1->type_common.main_variant)
 <integer_type 0x7ffff6922b28 wchar_t SI
    size <integer_cst 0x7ffff67f40a0 type <integer_type 0x7ffff67f00a8
bitsizetype> constant 32>
    unit size <integer_cst 0x7ffff67f40c0 type <integer_type 0x7ffff67f0000
sizetype> constant 4>
    align 32 symtab 0 alias set -1 canonical type 0x7ffff67f05e8 precision 32
min <integer_cst 0x7ffff67f4040 -2147483648> max <integer_cst 0x7ffff67f4060
2147483647> context <translation_unit_decl 0x7ffff67fbf18 D.2366>
    pointer_to_this <pointer_type 0x7ffff6922a80>>

ouch.  With the following asserts the testcase can possibly be reduced:

Index: gcc/tree-streamer-in.c
===================================================================
--- gcc/tree-streamer-in.c      (revision 192359)
+++ gcc/tree-streamer-in.c      (working copy)
@@ -703,6 +703,7 @@ lto_input_ts_type_common_tree_pointers (
   /* Do not stream TYPE_NEXT_VARIANT, we reconstruct the variant lists
      during fixup.  */
   TYPE_MAIN_VARIANT (expr) = stream_read_tree (ib, data_in);
+  gcc_assert (TYPE_MAIN_VARIANT (expr) == TYPE_MAIN_VARIANT (TYPE_MAIN_VARIANT
(expr)) || TYPE_MAIN_VARIANT (TYPE_MAIN_VARIANT (expr)) == NULL_TREE);
   TYPE_CONTEXT (expr) = stream_read_tree (ib, data_in);
   /* TYPE_CANONICAL gets re-computed during type merging.  */
   TYPE_CANONICAL (expr) = NULL_TREE;
Index: gcc/tree-streamer-out.c
===================================================================
--- gcc/tree-streamer-out.c     (revision 192359)
+++ gcc/tree-streamer-out.c     (working copy)
@@ -612,6 +612,7 @@ write_ts_type_common_tree_pointers (stru
      reconstructed during fixup.  */
   /* Do not stream TYPE_NEXT_VARIANT, we reconstruct the variant lists
      during fixup.  */
+  gcc_assert (TYPE_MAIN_VARIANT (expr) == TYPE_MAIN_VARIANT (TYPE_MAIN_VARIANT
(expr)));
   stream_write_tree (ob, TYPE_MAIN_VARIANT (expr), ref_p);
   stream_write_tree (ob, TYPE_CONTEXT (expr), ref_p);
   /* TYPE_CANONICAL is re-computed during type merging, so no need



More information about the Gcc-bugs mailing list