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

Reply via email to