[Bug lto/41767] New: assertion in tree-sra.c

[Bug lto/41767] New: assertion in tree-sra.c

[espindola at gcc dot gnu dot org]

To reproduce:

cc1 c-typeck.i -quiet -O2 -flto -o c-typeck.s 
cc1 c-parser.i -quiet -O2 -flto -o c-parser.s
as -o c-typeck.o c-typeck.s
as -o c-parser.o c-parser.s

lto1  -O2 c-typeck.o c-parser.o -o /dev/null


-- 
           Summary: assertion in tree-sra.c
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: espindola at gcc dot gnu dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug lto/41767] assertion in tree-sra.c

[espindola at gcc dot gnu dot org]

------- 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=18837&action=view)
testcase


-- 


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

[Bug lto/41767] assertion in tree-sra.c

[espindola at gcc dot gnu dot org]

------- 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=18839&action=view)
testcase


-- 


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

[Bug lto/41767] assertion in tree-sra.c

[espindola at gcc dot gnu dot org]

------- 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=18840&action=view)
testcase


-- 


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

[Bug lto/41767] assertion in tree-sra.c

[espindola at gcc dot gnu dot org]

------- 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=18838&action=view)
testcase


-- 


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

[Bug lto/41767] assertion in tree-sra.c

[rguenth at gcc dot gnu dot org]

------- 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|0000-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

[jamborm at gcc dot gnu dot org]

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

[rguenth at gcc dot gnu dot org]

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

[rguenth at gcc dot gnu dot org]

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

[jamborm at gcc dot gnu dot org]

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

[rguenth at gcc dot gnu dot org]

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.  With improved type-merging these kind of errors no longer happen.