[Bug analyzer/111312] New: Should the analyzer run earlier?

[Bug analyzer/111312] New: Should the analyzer run earlier?

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312

            Bug ID: 111312
           Summary: Should the analyzer run earlier?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
            Blocks: 111095, 111213
  Target Milestone: ---

I made the analyzer run when it does in order to take advantage of the LTO
streaming representation.

But:
  I'm having to recommend disabling optimizations for various -fanalyzer
warnings:
    * -Wanalyzer-deref-before-check
    * -Wanalyzer-infinite-recursion
    * -Wanalyzer-tainted-assertion
  and eventually:
    * -Wanalyzer-infinite-loop (work-in-progess; see bug 106147)

Also, various bugs are showing up where the analyzer fails to warn on clearly
wrong code (presumably due to the optimizer removing code containing undefined
behavior before the analyzer ever sees it; see e.g. bug 111095 and bug 111213).

Also: there's a tension between warnings and optimization: the optimizer takes
advantage of undefined behavior (assuming it's not present), but we want to
complain about the presence of undefined behavior.

Plus it's better to report things to the user in a form closer to that in which
they wrote the code.

When should we run?
  * immediately after we reach "generic"
    * could give us per-argument locations at call sites
  * once we're in gimple-cfg (but no ssa?)
  * once we're in gimple-ssa

Costs/Benefits of running at different times
  * is inlining saving us?
  * do we want to use the callgraph?
  * do we want to use the loop information? (see bug 109252)
  * do we want to use ranger? (need SSA)
  * do we want to use the CFGs?
  * do we want to reuse ipa-devirt?
  * presumably we don't want to reimplement lowering of OpenMP, exceptions, etc
  * PR analyzer/100116 ("analyzer event messages for conditionals have the
sense of the gimple IR rather than the source")

We're not currently analyzing the user's code, we're analyzing the user's code
after the optimizer has manipulated it, taking advantage of undefined behavior.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095
[Bug 111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];`
at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213
[Bug 111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at
-O1 and above

[Bug analyzer/111312] Should the analyzer run earlier?

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Richi: IIRC we chatted about this at last year's Cauldron, and wonder if you
have any thoughts on this  (and I'm very much looking forward to your
"Undefined behaviour and its treatment within GCC" Cauldron talk this year).

[Bug analyzer/111312] Should the analyzer run earlier?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the analyzer runs at the "correct" place as a regular IPA pass which
makes it possible for it to see the whole program (with -flto).

As with any of our late diagnostic passes there's trade-off when optimizing
less or more.

It should be possible to use -fanalyzer -flto -O0, correct?

The main question to me is whether -fanalyzer is supposed to be a
static analyzer only operation, thus the produced object files are really
an unwanted artifact.  If not, and -fanalyzer should be useful for full
release builds then I think -fanalyzer vs. -fno-analyzer shouldn't have
any effect on code generation (much like diagnostic options), but then
one might argue splitting analyzer into two phases, one early, for example
after SSA rewrite where most early diagnostic passes reside, and one
late, where it currently resides, would be appropriate to divert analyses
prone to false positives/negatives when run on optimized code early.  But
then duplicate diagnostics would have to be suppressed somehow (or the
result processed by tooling which could even correlate early/late findings).

[Bug analyzer/111312] Should the analyzer run earlier?

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Another example can be seen here:
  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628759.html
in:
  gcc/testsuite/c-c++-common/analyzer/overlapping-buffers.c
where -Wanalyzer-overlapping-buffers only catches cases that the optimizer
doesn't see; others it misses due to them being optimized away due to undefined
behavior.