[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[hubicka at gcc dot gnu.org]

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

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org ---
Fixed.

[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org ---
Author: hubicka
Date: Wed Sep 10 06:33:36 2014
New Revision: 215105

URL: https://gcc.gnu.org/viewcvs?rev=215105root=gccview=rev
Log:

PR ipa/63166
* ipa-prop.c (compute_known_type_jump_func): Fix conditional.

* g++.dg/lto/pr63166_0.ii: New testcase.
* g++.dg/lto/pr63166_1.ii: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr63166_0.ii
trunk/gcc/testsuite/g++.dg/lto/pr63166_1.ii
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org ---
Here I get:
Determining dynamic type for call: OBJ_TYPE_REF(_76;(struct
Foobar_Out)Foobar_LOG.D.2901-0) (Foobar_LOG.D.2901,  , 1);
  Starting walk at: _69 = MEM[(struct Foobar_Out
*)Foobar_LOG]._vptr.Foobar_Out;
  instance pointer: Foobar_LOG.D.2901  Outer instance pointer: Foobar_LOG
offset: 0 (bits) vtbl reference: MEM[(struct Foobar_Out
*)Foobar_LOG]._vptr.Foobar_Out
  Function call may change dynamic type:_35 = getName (_50(D), _33);
  Function call may change dynamic type:_33 = operator* (caller_it);
  Function call may change dynamic type:_31 = atEnd (caller_it);
  Function call may change dynamic type:getCallerIterator (_26);
  Function call may change dynamic type:_26 = OBJ_TYPE_REF(_24;(const struct
ECell)_44-0) (_44);
  Function call may change dynamic type:D.2965 = OBJ_TYPE_REF(_21;(struct
ECellList)_19-1) (_19, D.2966);
  Function call may change dynamic type:_19 = getCellList (_49(D));
  Function call may change dynamic type:p_cl_it_14 = OBJ_TYPE_REF(_12;(const
struct ECellList)_9-0) (_9);
  Function call may change dynamic type:_9 = getCellList (_43(D));
  Function call may change dynamic type:operator delete (p_cl_it_14);
  Checking vtbl store: MEM[(struct HashMapIterator
*)p_cl_it_14]._vptr.HashMapIterator = MEM[(void
*)_ZTV15HashMapIteratorI6EIdentP5ECell15DBHashFunctionsE + 16B];
base:MEM[(struct HashMapIterator *)p_cl_it_14] does not match
instance:Foobar_LOG
  Unanalyzed store may change type.
  Function call may change dynamic type:OBJ_TYPE_REF(_16;(struct
CellListIterator)p_cl_it_14-1) (p_cl_it_14);
  Function call may change dynamic type:_31 = atEnd (caller_it);
  Function call may change dynamic type:OBJ_TYPE_REF(_76;(struct
Foobar_Out)Foobar_LOG.D.2901-0) (Foobar_LOG.D.2901,  , 1);
  Function call may change dynamic type:_35 = getName (_50(D), _33);
  Function call may change dynamic type:_33 = operator* (caller_it);
  Targets of polymorphic call of type 0:struct Foobar_Out token 0
Contained in type:struct Foobar_Log at offset 0
This is a complete list. (base types included)
   Foobar_Log::put_to_buf/109 (no definition)
 Targets that are not likely:
   Foobar_Out::put_to_buf/108 (no definition)

I seem to agree that the memory store may potentially be vtable store for the
object in question.  I need to check how the old code gets around it...

[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
Aha, is_global_var test going wrong way. I am testing:
Index: ipa-prop.c
===
--- ipa-prop.c  (revision 215023)
+++ ipa-prop.c  (working copy)
@@ -1537,8 +1537,8 @@ compute_known_type_jump_func (tree op, s
call, current_function_decl)
   /* Even if the var seems to be in construction by inline call stack,
 we may work out the actual type by walking memory writes.  */
-   (!is_global_var (base)
-  detect_type_change (op, base, expected_type, call, jfunc,
offset)))
+   (is_global_var (base)
+ || detect_type_change (op, base, expected_type, call, jfunc,
offset)))
 return;

   ipa_set_jf_known_type (jfunc, offset, TREE_TYPE (base),

[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[hubicka at gcc dot gnu.org]

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

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-09-08
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
Mine.

[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
Created attachment 33448
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33448action=edit
Test file two.ii

[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.0