[Bug c++/106901] New: False positive -Warray-bounds with -O2 or higher?

[Bug c++/106901] New: False positive -Warray-bounds with -O2 or higher?

[carlosgalvezp at gmail dot com]

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

            Bug ID: 106901
           Summary: False positive -Warray-bounds with -O2 or higher?
           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!

Here's some code snippet that I believe leads to a false positive for
Warray-bounds. It happens in trunk but not on GCC 12.2.

#include <array>

bool bar(std::array<int, 5> const& vec,
         std::size_t const size,
         std::size_t const expected_size)
{
    if (size < expected_size)
    {
        return false;
    }
    for (std::size_t i{expected_size}; i < size; ++i)
    {
        if (vec[i] != 0)
        {
            return false;
        }
    }
    return true;
}

bool foo(std::array<int, 5> const& vec, std::size_t const size)
{
    return bar(vec, size, 5);
}

In file included from <source>:1:
In member function 'constexpr const std::array<_Tp, _Nm>::value_type&
std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = int; long
unsigned int _Nm = 5]',
    inlined from 'bool bar(const std::array<int, 5>&, std::size_t,
std::size_t)' at <source>:13:18,
    inlined from 'bool foo(const std::array<int, 5>&, std::size_t)' at
<source>:23:15:
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array:213:24:
warning: array subscript 5 is above array bounds of 'std::__array_traits<int,
5>::_Type' {aka 'const int [5]'} [-Warray-bounds]
  213 |         return _M_elems[__n];
      |                ~~~~~~~~^
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array: In function
'bool foo(const std::array<int, 5>&, std::size_t)':
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array:109:55:
note: while referencing 'std::array<int, 5>::_M_elems'
  109 |       typename __array_traits<_Tp, _Nm>::_Type        _M_elems;
      |                                                       ^~~~~~~~

Example on Compiler Explorer:
https://godbolt.org/z/dKWdKrsTa

Since "size" is unknown to the compiler, it shouldn't be possible to tell with
certainty whether the loop is actually executed and therefore out-of-bounds
invoked.

Thanks!

[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe I am reading the code wrong.
But size will be >= 5 at the loop.

So it will be executed. If size is >= 5. And that is what the warning is about.

[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?

[carlosgalvezp at gmail dot com]

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

--- Comment #2 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
If size == 5, expected_size == 5, then the loop is not executed, right?

[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes if size is 5, then yes it will not be executed.
There is another bug about the wording of the warning. The warning is saying
there might be an out of bounds due to the bounds of the loop is not bounded on
the size of the array.

[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?

[carlosgalvezp at gmail dot com]

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

--- Comment #4 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Makes sense!

Would it make sense to classify this as "maybe-array-bounds" instead? Similar
to "maybe-uninitialized" vs "uninitialized"

[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?

[carlosgalvezp at gmail dot com]

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

--- Comment #5 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
I also would like to understand why the warning is not triggered if the first
"if (size < expected_size)" is removed. 

https://godbolt.org/z/7vqPxhsqo

The possibility of executing the loop and do out-of-bounds still exists, right?
So why is the compiler warning in one case and not other?

Similarly, a regular for-loop with "size" known at runtime is equally risky,
yet the compiler is not flagging it:

bool bar(std::array<int, 5> const& vec,
         std::size_t const size)
{
    for (std::size_t i{0}; i < size; ++i)
    {
        if (vec[i] != 0)
        {
            return false;
        }
    }
    return true;
}

https://godbolt.org/z/6c64MEY7d

Personally, I think this warning should only warn about 100% confirmed OOB
cases, and put the "maybe" cases in a separate flag. All respectable projects
have as minimum "-Wall -Werror" in their compiler flags, to detect problems
that do exist, not that "might" exist. This can lead to quite a few false
positives, leading to people either disabling the warning altogether (which is
pretty bad!) or polluting the code with inline pragmas (disallowed by some
coding guidelines).

[Bug tree-optimization/106901] [13 Regression] False positive -Warray-bounds with -O2 or higher?

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
            Summary|False positive              |[13 Regression] False
                   |-Warray-bounds with -O2 or  |positive -Warray-bounds
                   |higher?                     |with -O2 or higher?
          Component|c++                         |tree-optimization
      Known to work|                            |12.2.0
             Blocks|                            |56456
         Resolution|---                         |INVALID
   Target Milestone|---                         |13.0

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think this is invalid.  We inline bar into foo and see

 if  (size < 5)
  return false;
 for (i = 5; i < size; ++i)
   if (vec[i] != 0)
   ....

so we know that vec[5] is accessed when the loop is executed which is out of
bounds and we diagnose that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/106901] [13 Regression] False positive -Warray-bounds with -O2 or higher?

[carlosgalvezp at gmail dot com]

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

--- Comment #7 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
I understand the reasoning, but the loop _can_ executed in other cases where
the function is called with different arguments:

bar(vec, 5, 5);  // Warray-bounds, loop not executed, no runtime OOB.
bar(vec, 5, 4);  // No Warray-bounds, loop executed,  no runtime OOB.

There is no OOB access in either case, so the compiler is incorrect in claiming
there is one. If there were, the OOB access would show up in Valgrind or ASan,
which is not the case.

Please note that the presence of False Positives in basic compiler warnings
like Wall or Wextra damages the credibility of compiler warnings. Warnings that
may have FPs should go in a different category, or as part of a separate tool,
like a static analyzer.