https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
--- Comment #6 from Teresa Johnson <tejohnson at google dot com> --- My new code is exposing an upstream profile count insanity that is being introduced by the copyrename2 phase. The new freqs_to_counts_path routine is invoked only when we don't have profile info, and in this case main() is in mozilla-xremote-client.ii which does not have a gcda file. So the profile status for the fn != PROFILE_READ. Before copyrename2, all the counts in main() are 0, and everything looks fine. But coming out of copyrename2, some of the blocks and edges have a count == 1. So my assert in freqs_to_counts_path that expects the edges to all have 0 weight is firing. The two approaches I could take are to either skip freqs_to_counts if there are actually non-zero counts or simply remove the assert with a comment about upstream insanities. I am probably going to do the latter, because the former will result in really insane frequencies coming out of jump threading (the updates are based on counts, which in this case are bogus coming in). It would be good to figure out why copyrename2 is introducing non-zero counts, but presumably there is some kind of profile update that has an off-by-one error? I don't see any count manipulation within tree-ssa-copyrename.c itself.
