> 2) The clang invocations don't need -fcaret-diagnostics
> -fshow-source-location -fdiagnostics-fixit-info because they are the
> default.
>
> 3) It's best to not pass -fdiagnostics-print-source-range-info unless
> you're looking for machine interpretable output. This flag adds
> things like {3:29-3:32} which are useful to a machine, but otherwise
> just clutter the output up.
>
> 4) It looks like ICC defaults to a number of coding standards types
> of checks, e.g. "access control not specified". I don't know if it
> is possible to turn those off, but they seem to just be noise for the
> purposes of this comparison.
I'll look into this. Some of this is over-zealousness on my part and
not wanting to miss a diagnostics flag. If I could make the diagnostics
more verbose I tried to not miss an opportunity to twist a knob.
The actual flags I compiled the data with are in this script and may
vary from the total listing at the top of the webpage.
http://people.redhat.com/bkoz/diagnostics/make-diagnostic-output.sh
> 5) There are a couple cases of GCC rejecting valid code (e.g. 19377),
> or which there may be some debate about (19538) it might be worth
> pointing this out. *shrug*
One of the goals was to measure the output when the input is
truncated, or obviously flawed (no semicolons is very
common!). Certainly if you can think of other (obvious) issues where
refactoring or haste make general classes of errors I'm very interested
in this particular type of pathology.
The valid code issues I can flag in the existing bug reports.
thanks,
benjamin
