https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-03-27
CC| |hubicka at gcc dot gnu.org
Target Milestone|--- |8.0
Summary|LTO ICE: tree check: |[8 Regression] LTO ICE:
|expected tree that contains |tree check: expected tree
|'decl minimal' structure, |that contains 'decl
|have 'identifier_node' in |minimal' structure, have
|decl_mangling_context, at |'identifier_node' in
|cp/mangle.c:878 |decl_mangling_context, at
| |cp/mangle.c:878
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So this is the devirt machinery "late" creating a cgraph node and computing a
DECL_ASSEMBLER_NAME _after_ free-lang-data killed TYPE_NAME of an entity
said to be ! type_with_linkage_p (type)
More specifically:
#22 0x0000000000ec6681 in gimple_get_virt_method_for_vtable (token=0,
v=<var_decl 0x7ffff6a09360 _ZTV1e>, offset=128, can_refer=0x7fffffffd377)
at /space/rguenther/src/svn/early-lto-debug/gcc/gimple-fold.c:6895
6895 cgraph_node::get_create (fn);
(gdb) p debug_generic_expr (fn)
c
and down via DECL_ASSEMBLER_NAME:
#4 0x00000000009a09b6 in write_name (
decl=<identifier_node 0x7ffff68acc00 __va_list_tag>, ignore_local_scope=0)
at /space/rguenther/src/svn/early-lto-debug/gcc/cp/mangle.c:906
906 context = decl_mangling_context (decl);
(gdb)
#5 0x00000000009ab761 in write_class_enum_type (
type=<record_type 0x7ffff68bbd20 __va_list_tag>)
at /space/rguenther/src/svn/early-lto-debug/gcc/cp/mangle.c:2809
2809 write_name (TYPE_NAME (type), /*ignore_local_scope=*/0);
(gdb) p type_with_linkage_p (0x7ffff68bbd20)
$2 = false
which is because of
201 /* Builtin types do not define linkage, their TYPE_CONTEXT is NULL.
*/
202 if (!TYPE_CONTEXT (t))
203 return false;
but to me the more important question is why we didn't assign the
assembler name for this entity before fld. This is because we do not
find it during the walk of the IL. Maybe because we do not walk
vtable initializers? Looks like vtables are not in varpool, so we
have to find them via walking BINFOs which we do not seem to do.
Looks like walking BINFO_TYPE/BINFO_VTABLE isn't enough to reach the
vtable entry either. Neither via the call stmts obj_type_ref_class.
So Honza, how do we reach the "correct" 'c'? I tried
Index: tree.c
===================================================================
--- tree.c (revision 258851)
+++ tree.c (working copy)
@@ -5522,6 +5522,8 @@ find_decls_types_r (tree *tp, int *ws, v
FOR_EACH_VEC_ELT (*BINFO_BASE_BINFOS (TYPE_BINFO (t)), i, tem)
fld_worklist_push (TREE_TYPE (tem), fld);
fld_worklist_push (BINFO_VIRTUALS (TYPE_BINFO (t)), fld);
+ fld_worklist_push (BINFO_TYPE (tem), fld);
+ fld_worklist_push (BINFO_VTABLE (tem), fld);
}
if (RECORD_OR_UNION_TYPE_P (t))
{
@@ -5700,7 +5702,11 @@ find_decls_types_in_node (struct cgraph_
gimple *stmt = gsi_stmt (si);
if (is_gimple_call (stmt))
- find_decls_types (gimple_call_fntype (stmt), fld);
+ {
+ find_decls_types (gimple_call_fntype (stmt), fld);
+ if (virtual_method_call_p (gimple_call_fn (stmt)))
+ find_decls_types (obj_type_ref_class (gimple_call_fn (stmt)),
fld);
+ }
for (i = 0; i < gimple_num_ops (stmt); i++)
{
