https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79776
--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
The second time insert_vi_for_tree is called on the same decl, it is
from is from associate_varinfo_to_alias (itself called from
call_for_symbol_thunks_and_aliases), which is looking at a
(speculatively) inlined thunk:
(gdb) p node->thunk.thunk_p
$26 = true
(gdb) p node->global.inlined_to
$27 = <symtab_function 0x7ffff6a0b170 fn2/0>
(gdb) p node->callers->speculative
$30 = 1
While I feel sympathetic for any user of
call_for_symbol_thunks_and_aliases which does not expect to be handed
such a beast, I am not sure if they can ignore it. The problem is
that this inlining apparently has not been performed on the gimple
level yet and so looking at caller's body will not give you the
correct idea about the situation. invoking "call debug_function(
node->callers->caller->decl, 0)" in gdb confirms this but I do not
want to be pasting this here. Moreover, there is already no edge from
the thunk caller to the original callee, so anybody ignoring the
inlined thunk is going to miss that "call" altogether.
So I'd lean against changing call_for_symbol_thunks_and_aliases.
OTOH, if I understand associate_varinfo_to_alias well, I think that
ignoring nodes with node->global.inlined_to set there seems like a
reasonable (though untested) fix:
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index c043e5ec3a6..06be189e1d1 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -7616,7 +7616,8 @@ static bool
associate_varinfo_to_alias (struct cgraph_node *node, void *data)
{
if ((node->alias || node->thunk.thunk_p)
- && node->analyzed)
+ && node->analyzed
+ && !node->global.inlined_to)
insert_vi_for_tree (node->decl, (varinfo_t)data);
return false;
}
