[Bug analyzer/108432] New: Analyzer fails to detect out-of-bounds issues within loops

[Bug analyzer/108432] New: Analyzer fails to detect out-of-bounds issues within loops

[dmalcolm at gcc dot gnu.org]

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

            Bug ID: 108432
           Summary: Analyzer fails to detect out-of-bounds issues within
                    loops
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Consider:
  https://samate.nist.gov/SARD/test-cases/149169/versions/2.0.0

Without optimization, gcc trunk with -fanalyzer fails to report the
out-of-bounds write:
  https://godbolt.org/z/brx5cT18o

At -O1 and above (https://godbolt.org/z/PdvcE5MhE), we get:

<source>: In function 'main':
<source>:22:25: warning: iteration 9 invokes undefined behavior
[-Waggressive-loop-optimizations]
   22 |                 bStr[i] = (char)i + 'a';                               
                /* FLAW */
      |                 ~~~~~~~~^~~~~~~~~~~~~~~
<source>:21:23: note: within this loop
   21 |         for (i = 1; i <= 10; ++i)
      |                     ~~^~~~~

The analyzer probably ought to try to at least check the final iteration of a
loop (I believe it currently will at least detect issues in the initial
iteration of a loop).

[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

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

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Many warning messages are also dependent on optimisation level.  And the
actual generated code is as well ;-)

-O0 means do the least possible work to generate correct code.  There is
friction between that and having -fanalyzer do deep inspection of the code.
I think we should document -fanalyzer needs some optimisation enabled (does
it need -O2 in some cases, or just -O1 always, btw?)

The suggestion to at least check the last loop iteration is good of course.

[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #1)
> Many warning messages are also dependent on optimisation level.  And the
> actual generated code is as well ;-)
> 
> -O0 means do the least possible work to generate correct code.  There is
> friction between that and having -fanalyzer do deep inspection of the code.
> I think we should document -fanalyzer needs some optimisation enabled (does
> it need -O2 in some cases, or just -O1 always, btw?)
> 
> The suggestion to at least check the last loop iteration is good of course.

Unfortunately, some analyzer warnings work better with optimization *disabled*.
 -fanalyzer runs much later than most other static analyzers.

For example, -Wanalyzer-deref-before-check doesn't work well with optimization,
as the dereference means that that optimized can remove the checks before the
analyzer "sees" them.

I think there's a natural tension between optimization and detecting undefined
behavior, in that -fanalyzer wants to report on possible undefined behavior,
whereas optimization wants to take advantage of undefined behavior.

[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #2)
> Unfortunately, some analyzer warnings work better with optimization
> *disabled*.  -fanalyzer runs much later than most other static analyzers.

Understood.  But some work better with it enabled, right?

> For example, -Wanalyzer-deref-before-check doesn't work well with
> optimization, as the dereference means that that optimized can remove the
> checks before the analyzer "sees" them.

Yes.

> I think there's a natural tension between optimization and detecting
> undefined behavior, in that -fanalyzer wants to report on possible undefined
> behavior, whereas optimization wants to take advantage of undefined behavior.

"Take advantage of"...  A program that contains UB is erroneous, has no
defined semantics *at all*, so what the compiler is really doing is assuming
the program is a correct program, and generating more optimal target code
based on that not unreasonable assumption.

This sounds a bit better, right?  It still is true that the compiler cannot
detect all UB during compilation (it needs to know the program's input as
well for that, and even then it isn't realistic).  Is it even possible to
detect *all* UB at runtime?

[Bug analyzer/108432] RFE: analyzer could detect out-of-bounds issues within loops

[dmalcolm at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Analyzer fails to detect    |RFE: analyzer could detect
                   |out-of-bounds issues within |out-of-bounds issues within
                   |loops                       |loops

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Retitling this to be an RFE, since handling these cases is an expansion of the
scope of -fanalyzer's bounds-checker.

[Bug analyzer/108432] RFE: analyzer could detect out-of-bounds issues within loops

[dmalcolm at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamie.bainbridge at gmail dot com

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
*** Bug 107566 has been marked as a duplicate of this bug. ***

[Bug analyzer/108432] RFE: analyzer could detect out-of-bounds issues within loops

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Another example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598#c2