2014-05-30 13:40 GMT-07:00 Bob Wilson <[email protected]>: > > 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. > > Alex, do you think that will work? >
Yes, that should work.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
