https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108535
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2023-01-26
Status|UNCONFIRMED |WAITING
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
As I understand it, cppcheck's attempts to explore all combinations of possible
preprocessor defines.
GCC's -fanalyzer performs coverage-guided symbolic execution to try to explore
the various execution paths in the user's code. It runs on GCC's intermediate
representation as the code is being compiled. In particular -fanalyzer runs
internally *after* preprocessing; it uses just the specific defines that the
file was invoked with (via -D at the command-line, or via #defines in headers,
etc).
So I don't think GCC's -fanalyzer can support the "all combinations of
preprocessor defines" approach; it would be a total rewrite.
It sounds like what you really want is for GCC -fanalyzer to be faster on this
particular translation unit. If so, I can try digging into it to see where the
slowdown happens.
