On Mon, 13 Mar 2017, Martin Liška wrote: > On 03/13/2017 02:01 PM, Richard Biener wrote: > > On Mon, 13 Mar 2017, Richard Biener wrote: > > > >> On Fri, 10 Mar 2017, Martin Liška wrote: > >> > >>> Hello. > >>> > >>> As briefly discussed in the PR, there are BB that do not correspond to a > >>> real > >>> line in source > >>> code. profile.c emits locations for all BBs that have a gimple statement > >>> belonging to a line. > >>> I hope these should be marked in gcov utility and not added in --all-block > >>> mode to counts of lines. > >>> > >>> Patch survives make check RUNTESTFLAGS="gcov.exp". > >>> > >>> Thanks for review and feedback. > >> > >> Humm, the patch doesn't seem to change the BBs associated with a line > >> but rather somehow changes how we compute counts (the patch lacks a > >> description of how you arrived at it). I expected the line-to-BB > >> assignment process to be changed (whereever that is...). > > Currently, each basic block must belong to a source line. It's how gcov > iterates all blocks (via lines). > > > > > Ah, ok, looking at where output_location is called on I see we do not > > assign any line to that block. But still why does > > line->has_block (arc->src) return true? > > Good objection! Problematic that 4->5 edge really comes from the same line. > > <bb 4> [0.00%]: > ret_7 = 111; > PROF_edge_counter_10 = __gcov0.UuT[0]; > PROF_edge_counter_11 = PROF_edge_counter_10 + 1; > __gcov0.UuT[0] = PROF_edge_counter_11; > > <bb 5> [0.00%]: > # ret_1 = PHI <ret_5(3), ret_7(4)> > goto <bb 7>; [0.00%]
Yes, but that's basically meaningless, unless not all edges come from the same line? I see nowhere where we'd explicitely assign lines to edges so it must be gcov "reconstructing" this somewhere. Richard. > Martin > > > > > Richard. > > > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
