On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote: > Needs review. msebor expressed some concerns in an earlier version > of the patch here: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00233.html > re overlap with existing functions, and very long names. > For the former, they all have a "-Wanalyzer-" prefix to > distinguish them, and for the latter, I prefer the precision > of the longer names, but tastes may vary. > > Changed in v5: > - update ChangeLog path > - updated copyright years to include 2020 > - fix a stray reference to plugins > > Changed in v4: > - Renamed gcc/analyzer/plugin.opt to gcc/analyzer/analyzer.opt > > - Change option from -analyzer to -fanalyzer, changed it from > Driver to Common. > > - Various commits on 2019-11-12 including r278083 through r278087 > reimplemented parameter-handling in terms of options, so that > params are defined in params.opt rather than params.def. > > This patch adds the params for the analyzer to analyzer.opt, > replacing the patch: > [PATCH 22/49] analyzer: params.def: new parameters > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01520.html > from the original version of the patch kit. > > - Added -Wanalyzer-unsafe-call-within-signal-handler from > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00214.html > > This patch contains the command-line options for the analyzer. > > gcc/analyzer/ChangeLog: > * analyzer.opt: New file. > > gcc/ChangeLog: > * common.opt (-fanalyzer): New driver option. So I like having the diagnostics in a different namespace. THat's inherently going to make their names longer. But yea, the names are a mouthfull. I also think that with the analyzer support still being preliminary that we have degrees of freedom to rename options, so I don't think that the lengths of the options should be a major blocker to moving this work forward.
WRT the overlap with existing warnings. I think there is going to be degrees of overlap. The question we're going to have to continually evaluate is where any particular warning belongs. We're still early, but I suspect a significant factor in that decision will be the degree of property tracking across calls/returns that's needed to have a useful warning. ISTM that once we have to track info across calls, then we're into the static analyzer and the higher overhead that's inherent in that style. So I'm inclined to ACK, knowing that we may end up coming back and renaming options related to the analyzer and that we're likely going to have cases where there is some degree of overlap between the analyzer and the older diagnostics. jeff >
