[Bug c++/107677] New: -Warray-bounds: unclear what exactly it's meant to detect

[Bug c++/107677] New: -Warray-bounds: unclear what exactly it's meant to detect

[carlosgalvezp at gmail dot com]

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

            Bug ID: 107677
           Summary: -Warray-bounds: unclear what exactly it's meant to
                    detect
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Hi,

I have a hard time understanding -Warray-bounds. The documentation says:

"It warns about subscripts to arrays that are always out of bounds"

And yet, none of the hits of the warning are caught by sanitizer, nor by
valgrind, nor by Clang. So how can it be that they "always" are out of bounds?
Surely they should have been caught by some other tool, if it were so obvious?

Some of the warnings go away if I "assert" that the subscript index is smaller
than the size of the array, even if the assertion is not needed. Is GCC warning
about "maybe" out of bounds cases, instead of "real" cases? 

Lastly, I find the stacktrace very confusing. It simply says "array subscript X
is out of bounds". Where does this X come from? Is it real (and if so, where in
the code is the number X defined?), or is it "a possibility" that may or may
not happen based on runtime input?

Thanks!

[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |middle-end
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Please provide some testcase we can compile, otherwise this isn't an actionable
bug report.

[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect

[carlosgalvezp at gmail dot com]

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

--- Comment #2 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
This is a general question which I hope can be answered without a full report.
My particular example gets a warning deep into Eigen-like code so it's not easy
to provide a minimal example.

My questions are code agnostic. Most importantly, I need to understand if this
warning is expected to produce false positives in it's default setting with
-Wall. The documentation says it catches subscripts that are "always" OOB. This
is not the case, as confirmed with other tools. So, is the documentation
accurate? Based on your experience with this warning, what type of code is it
expected to warn on? It would be good to add this as part of the documentation.

Finally, I ask if the subscript that GCC complains about is real or fictional
(namely, it "could" be OOB but GCC can't know it statically). We've seen other
warnings that complain about fictional numbers representing theoretical worst
case, for example the max number of an int when unrolling a loop, which is
possible in theory but unlikely in practice. Does this warning apply similar
heuristics?

[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect

[carlosgalvezp at gmail dot com]

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

--- Comment #3 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
The warning message is also hard to decipher. For example, what does this mean?

error: array subscript [-536870912, -1] is outside array bounds

What is a 2-dimensional subscript applied on a 1D array?

[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note range syntax of [a, b] is math syntax not to be confused with array
deference syntax of c.

[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect

[carlosgalvezp at gmail dot com]

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

--- Comment #5 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Wow, that was mind blowing, thanks for the clarification! Such thing I'd like
to have in the docs, it's very easy to confuse with the other message:

note: at offset 48 into object '<anonymous>' of size 48

So one offset is an actual index, and the other is a "mathematical range of
indices".

Back to my example:

error: array subscript [-536870912, -1] is outside array bounds

I don't see these numbers in my code. Therefore I wonder: how does GCC compute
these numbers? Are they based on my code, or are they based on: "if the user
pass you the number -536870912 as input at runtime, then you'll do
out-of-bounds"?

[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
If you supply a runtime index or pointer offset GCC tries to constrain that
value.  If it can constrain the index or pointer offset such that the access
would always be out of the bounds of an array that is accessed or offsetted
then this is an "always out of bounds" access to the diagnostic.

Consider

 int a[3];
 if (n > 1)
   return a[n];

here we'd constrain n to be in the range [2, INT_MAX] and _not_ diagnose
the a[n] reference (because '2' would be a valid index).  That's done to
not make imperfect range analysis cause diagnostics all over the place.

The most common reason for false positives is instead code that's never
executed at runtime but the intermediate language GCC works on allowed it
to constrain an access enough.  That's either a missed optimization in
case GCC should have been able to see it's eliminatable dead code it
warns on or "unfortunate" in that it cannot.  Often the constraints GCC
uses result from other optimizations that duplicate code.

Confusing is how GCC tries to second-guess the actual array you are
accessing when it just sees pointer arithmetic instead of clearly
communicating the offsetting of a pointer.