[PATCH] Don't error on coverage mismatch by request

[Jan Hubicka]

> 
> Which makes it even less useful to error on diagnosed mismatch... !?

Well, when the mismatch is diagnosed, you are positive profile is wrong,
so error seems useful.  The silently ignored cases happens when CFG
itself does not change much (so checksum match) but the program
behaviour does.  Bugfixes tend to have this behaviour in general.

> But you mean instead of saying "assuming zero counts" in addition
> say that "this can result in poorly optimized code" or just saying that
> in the documentation?

Well, if I try to reconstruct what random user will do, I would expect
is:

1) Profile application
2) Change something or do profiling wrong
3) Compile with feedback getting error
4) Searching documentation suggesting that he can use
-Wcoverage-mismatch to work around
5) Compile with feedback, profile and possibly be disappointed starting
to use -Wcoverage-mismatch more often without thinking about code
quality consequences.

So I would say that the documentation for -Wcoverage-mismatch should
warn about likeliness that resulting code will be slow when based on
outdated profile even when compiler does not diagnoze it.

Also concerning code quality, it would be more meaningful to arrange
tree-profile to give up early and set cfun->profile to PROFILE_ABSENT
so we end up with same code as if we didn't attempt to read code in.
Warning can then say "Will optimize without the profile" or something
like that...

Honza
> 
> Thanks,
> Richard.
> 
> >Honza
> >>
> >> Thanks,
> >> Richard.
> >>
> >> >2006-11-23  Richard Guenther  <rguenther@suse.de>
> >> >
> >> >        * doc/invoke.texi (-Wcoverage-mismatch): Document.
> >> >        * common.opt (-Wcoverage-mismatch): New warning option.
> >> >        * coverage.c (get_coverage_counts): Ignore coverage mismatch
> >> >        if -Wcoverage-mismatch is given.
> >