https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #16 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #13) > [...] > > Here are two calls to + and it is not clear which one triggers the ICE. > However sum += e->count.ipa (); quite obviously preserves the fact that sum > is an IPA count. So I think it is > > cs->count += desc->count > > which makes sense to me. dest->count is IPA count > if (cs->count.initialized_p ()) > desc->count += cs->count.ipa (); > > So I suppose what happens here is that we clone function with no profile > feedback available. This can happen in some cases, with profile mismatches > or with comdat merging. it is an incoming edge that has estimated profile, not the function. But yes. > > Martin, I think this is yours code, but I would say that if desc is IPA > count of 3694 while cs->count is locally estimated, we don't really have way > to add them together, so I would just skip the adjustment on > !cs->count.ipa_p () I think that the only thing we can do. I guess I should prepare a patch? > > However it is not clear to me how desc can be something non-zero in this > case? > From where the number comes? It is the difference between the count of the node and the sum of (ipa) counts of incoming edges, divided by the number of edges which have not yet been scaled. > > It is possible that we scaled down the profile from non-zero to 0 which > makes us to downgrade IPA profile to non-IPA, but in that case the updating > code attempts to do something fisly making call site within function with 0 > invocations to have non-zero count. > Yes, it might be because lenient_count_portion_handling kicked in.
