[Bug lto/41767] assertion in tree-sra.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767 Richard Biener changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Richard Biener --- Fixed. With improved type-merging these kind of errors no longer happen.
[Bug lto/41767] assertion in tree-sra.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767 Eric Gallager changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #13 from Eric Gallager --- (In reply to Eric Gallager from comment #12) > (In reply to Eric Gallager from comment #11) > > (In reply to Richard Biener from comment #10) > > > I will give the situation a more detailed look later (but yes, I believe > > > this > > > is invalid input to LTO). Let's defer a solution a bit. > > > > Has it been deferred long enough yet? > > WAITING on a reply Actually I guess SUSPENDED makes more sense if no one is working on it
[Bug lto/41767] assertion in tree-sra.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #12 from Eric Gallager --- (In reply to Eric Gallager from comment #11) > (In reply to Richard Biener from comment #10) > > I will give the situation a more detailed look later (but yes, I believe > > this > > is invalid input to LTO). Let's defer a solution a bit. > > Has it been deferred long enough yet? WAITING on a reply
[Bug lto/41767] assertion in tree-sra.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767 Eric Gallager changed: What|Removed |Added Keywords||deferred CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Richard Biener from comment #10) > I will give the situation a more detailed look later (but yes, I believe this > is invalid input to LTO). Let's defer a solution a bit. Has it been deferred long enough yet?
[Bug lto/41767] assertion in tree-sra.c
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-10-28 10:25 --- I will give the situation a more detailed look later (but yes, I believe this is invalid input to LTO). Let's defer a solution a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-10-27 13:59 --- The problem here is that build_ref_for_offset_1() cannot find a field corresponding to a replacement within its own aggregate. The field is identified by its offset (zero) and type. Unfortunately, types_compatible_p() claims that the type of the replacement (taken from the expression where it occurs) and the field at the offset are not compatible. I have added some dumps to the beginning of the function and got: -- picked field value Determining compatibility of types: Expected type (type of the scalar replacement): pointer_type 0xb7726514 type union_type 0xb772612c tree_node SI size integer_cst 0xb7687498 constant 32 unit size integer_cst 0xb7687284 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb772612c fields field_decl 0xb76eee60 common type record_type 0xb7720b54 tree_common SI file b.h line 8 col 20 size integer_cst 0xb7687498 32 unit size integer_cst 0xb7687284 4 align 32 offset_align 128 offset integer_cst 0xb76872a0 constant 0 bit offset integer_cst 0xb7687700 constant 0 context union_type 0xb772612c tree_node chain field_decl 0xb76eef18 constructor pointer_to_this pointer_type 0xb7726514 unsigned SI size integer_cst 0xb7687498 32 unit size integer_cst 0xb7687284 4 align 32 symtab 0 alias set 4 canonical type 0xb7726514 Record field type: pointer_type 0xb7720e10 type union_type 0xb7720af0 tree_node SI size integer_cst 0xb7687498 constant 32 unit size integer_cst 0xb7687284 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb7720af0 fields field_decl 0xb76eebdc common type record_type 0xb7720b54 tree_common SI file b.h line 8 col 20 size integer_cst 0xb7687498 32 unit size integer_cst 0xb7687284 4 align 32 offset_align 128 offset integer_cst 0xb76872a0 constant 0 bit offset integer_cst 0xb7687700 constant 0 context union_type 0xb7720af0 tree_node chain field_decl 0xb76eec94 constructor pointer_to_this pointer_type 0xb7720e10 unsigned SI size integer_cst 0xb7687498 32 unit size integer_cst 0xb7687284 4 align 32 symtab 0 alias set 3 canonical type 0xb7720e10 NOT compatible. -- I could workaround this and check whether all replacements can be located within their aggregates before creating them but that does not sound right. Instead I think that the bug is either somewhere in type merging or in types_compatible_p(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-27 14:17 --- As I said the testcase has two incompatible variants of union tree_node and they are obviously not merged and thus not compatible. Maybe IPA SRA gets those two types from unrelated places? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-27 14:22 --- Using c-parser.i and c-typeck.i generated from my current trunk tree passes gcc ./xgcc -B. -r -nostdlib xc-parser.i xc-typeck.i -O2 -flto just fine. Raphael, was this by chance an ICE you saw during reduction of another testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-10-27 18:39 ---
Hi,
(In reply to comment #7)
Maybe IPA SRA gets
those two types from unrelated places?
I believe they are quite elated. The body of the function is:
bb 2:
init = c_parser_initializer (0B); [return slot optimization]
init$value_5 = init.value;
finish_decl (0, 0, init$value_5, 0, 0);
return;
The expected type is type of the RHS of the second statement
init.value while the type I get is the type of value within init.
As I said the testcase has two incompatible variants of union tree_node and
they are obviously not merged and thus not compatible.
I was not sure whether you were implying that the input was invalid or
not. If it is and we want to avoid the ICE in the simplest possible
way, we can do so with the patch below. (Of course, we might try to
instead warn or fail in some nicer way when putting the individual
pieces from different files together.)
Index: mine/gcc/tree-sra.c
===
--- mine.orig/gcc/tree-sra.c
+++ mine/gcc/tree-sra.c
@@ -1644,7 +1644,13 @@ analyze_access_subtree (struct access *r
if (allow_replacements scalar !root-first_child
(root-grp_hint
- || (direct_read root-grp_write)))
+ || (direct_read root-grp_write))
+ /* If the user provided erroneous LTO intput, we might end up ICIng as
+in PR 41767. Prevent that by checking we can always find the part of
+the aggregate that corresponds to the replacement. */
+ (!in_lto_p
+ || build_ref_for_offset (NULL, TREE_TYPE (root-base),
+ root-offset, root-type, false)))
{
if (dump_file (dump_flags TDF_DETAILS))
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-21 12:18 ---
Confirmed. But the reduced testcase has
typedef struct VEC_constructor_elt_gc {
VEC_constructor_elt_base base;
} VEC_constructor_elt_gc;
vs.
typedef struct VEC_constructor_elt_gc {
} VEC_constructor_elt_gc;
which results in incompatible struct tree_constructor and thus union tree_node.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-21 12:18:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #1 from espindola at gcc dot gnu dot org 2009-10-20 17:54 --- Created an attachment (id=18837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18837action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #2 from espindola at gcc dot gnu dot org 2009-10-20 17:55 --- Created an attachment (id=18838) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18838action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #3 from espindola at gcc dot gnu dot org 2009-10-20 17:55 --- Created an attachment (id=18839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18839action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #4 from espindola at gcc dot gnu dot org 2009-10-20 17:55 --- Created an attachment (id=18840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18840action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
