[PATCH] decide edge's hotness when there is profile info

[Jan Hubicka]

> More info on the lto bootstrap failure:
> 
> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1:
> warning: Missing counts for called function pex_child_error.isra.1/73
> [enabled by default]
>  }
> 
> This is an error handling routine that invokes _exit. Looking at the
> ipa-profile dump, I can see that all the counts read in for
> pex_child_error have the value 0. But there is a non-zero callsite,
> that not surprisingly complains of a profile insanity in the bb's
> outgoing edge weights, since pex_child_error never returns:
> 
> ;;   basic block 38, loop depth 1, count 192, freq 5000
> ;;   Invalid sum of outgoing counts 0, should be 192
> ...
>   pex_child_error.isra.1D.5005 (_92, executable_40(D),
> [/usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c :
> 677] "execv", _91);
> ;;    succ:       3 [100.0%]  (ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
> 
> Not sure why the counts were all 0 for this routine though, I wouldn't
> think the early exit should prevent us from updating the counts. But
> IMO the best thing to do here is to issue a warning, since I don't
> want more issues like this to cause compile errors when we handled
> them fine before.
> 
> Let me know if the patch below is ok.

OK, so _exit actually makes us to miss streaming of the path leading to the
error message?  Handling of vfork is somewhat broken, as I noticed with Martin
Liska. One problem is that gcov_exit is not clearing the counts.  With vfork
being used in addition to execvs we stream out the data but the counts stays in
the oriignal process memory and then are streamed again.  If execve fails and
leads to _exit I think we can get the miscompare you see.

Does calling gcov_clear within gcov_exit help?  (It is what I have in our tree)

Honza