> 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