> Hi, Jan,
> 
> I am studying one profiling feedback ICE bug with GCC8 recently. 
> It’s an assertion failure inside the routine “compute_working_sets”of 
> gcov-io.c:
> 
> gcov_nonruntime_assert (ws_ix == NUM_GCOV_WORKING_SETS);
> 
> After some debugging and study, I found that the corresponding .gcda file has 
> two PROGRAM_SUMMARY sections:
> 
> foo.gcda:  a3000000: 202:PROGRAM_SUMMARY checksum=0x91f3e3ae 
> foo.gcda:                counts=10831, runs=0, sum_all=478965, 
> run_max=125615, sum_max=201126 
> foo.gcda:                counter histogram: 
> foo.gcda:                 0: num counts=10187, min counter=0, cum_counter=0 
> … 
> foo.gcda:                51: num counts=1, min counter=14524, 
> cum_counter=14524 
> foo.gcda:                63: num counts=1, min counter=125615, 
> cum_counter=125615 
> foo.gcda:  a3000000: 137:PROGRAM_SUMMARY checksum=0xcf9f0896 
> foo.gcda:                counts=10502, runs=1, sum_all=48618, run_max=13999, 
> sum_max=14046 
> foo.gcda:                counter histogram: 
> foo.gcda:                 0: num counts=9821, min counter=0, cum_counter=0 
> … 
> foo.gcda:                43: num counts=1, min counter=3830, cum_counter=3830 
> foo.gcda:                50: num counts=1, min counter=13999, 
> cum_counter=13999 
> 
> Looks like the 2nd PROGRAM_SUMMARY has some issue. If I manually change 
> gcc/coverage.c 
> to ignore the 2nd PROGRAM_SUMMARY section, the ICE disappears. 
> 
> I have several questions for the profiling feedback data file:
> 
> 1. Under what situation, there will be multiple PROGRAM_SUMMARY sections for 
> one module?

This is itended to resolve situations where one object file is linked
into multiple final binaries (just like libbackend is linked into
multiple FEs).  The overall binary checksum is known to
the runtime and it creates entry for each checksum.
> 2. How to check whether one of the PROGRAM_SUMMARY has issue?

The histograms was added by google to get better threshold for hot/cold
partitioning. They never worked too well, because it is hard to merge
histograms from multipe runs meaningfully, so we dropped them some time
ago.  With LTO it is easier to produce the histogram after reading all
profiles together and without LTO we use easier heuristics that only
computes constant fraction of maximum number of iterations.

What confuses me is the first summary having runs=0.  I wonder how with
zero runs it even has an entry?

What is the assert that fials in gcov-io.c?

Honza

> 
> Thanks a lot for any help.
> 
> Qing

Reply via email to