This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2
- From: "marxin at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 28 Mar 2017 08:31:13 +0000
- Subject: [Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2
- Auto-submitted: auto-generated
- References: <bug-79931-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79931
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I can confirm that, it's not Ubuntu specific, easily reproducible on current
trunk.
Issues is that ODR type graph is built dynamically, starting just with types of
methods. During gimplification of functions, possible_polymorphic_call_targets
is asked and known results are put into polymorphic_call_target_hash. Problem
comes when a type receives a new derived type which can add possible target.
This happens in your test-case.
I prepared a simple patch validating that # of targets does not change during
time in the cache and there's example that fails:
class b
{
protected:
enum
{
c
};
virtual void d (int a) const;
bool e ();
char f;
};
bool
b::e ()
{
d (123);
}
class g : b
{
void
d (int a) const
{
}
};
>From possible 2 targets, new result would be 1. Still it's partial list and
that can probably just make worse decisions.
But still, the inconsistency should be probably handled.
Honza?