On Fri, May 30, 2014 at 1:40 PM, Bob Wilson <[email protected]> wrote: > > On May 28, 2014, at 4:11 PM, Eric Christopher <[email protected]> wrote: > >> On Wed, May 28, 2014 at 4:08 PM, Duncan P. N. Exon Smith >> <[email protected]> wrote: >>> >>>> On 2014-May-28, at 15:55, Eric Christopher <[email protected]> wrote: >>>> >>>> ... I'll bite. >>>> >>>> Why do you want to know "this function wasn't instrumented" versus >>>> "this had no calls" for coverage? If it's not instrumented it's >>>> definitely not called. Otherwise you need to do this for all functions >>>> (and who knows what chaos with special member functions that you >>>> didn't have to create... :) >>> >>> I can think of two scenarios: >>> >>> 1. The error/warning messages should be different: "profile out of date" vs. >>> "foo() has no coverage". >> >> This seems ok I guess. Though if you've got a binary you should be >> able to say "this code doesn't exist". >> >>> >>> 2. All you have is source and the profile data (i.e., a gcov-like flow, >>> without an AST), and you want to output the list of functions with no >>> coverage. >> >> You could just take the ones that you do have coverage info for and >> it's the inverse? >> >> In general I think forcing emission of things that aren't normally >> emitted is probably going to be a bit of a problem. > > I think Eric is right here. > > Instead of emitting the functions, we should be able to solve this by > emitting something to the coverage mapping table (something Alex is starting > to work on) to just hardwire the counts for these unused functions to zero. >
Sounds about like what Duncan and I were talking about on IRC after (apologies for not updating the thread). What do you mean for a coverage mapping table? -eric > Alex, do you think that will work? _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
