[Bug middle-end/104965] New: Yet another -Warray-bounds false positive

[Bug middle-end/104965] New: Yet another -Warray-bounds false positive

[redi at gcc dot gnu.org]

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

            Bug ID: 104965
           Summary: Yet another -Warray-bounds false positive
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
            Blocks: 56456
  Target Milestone: ---

Maybe another dup, I can't keep track.

#include <string>

template<typename T>
T* f(const std::basic_string<T>& str)
{
  auto n = str.size();
  auto p = new T[n];
  str.copy(p, n);
  return p;
}

int main()
{
  std::basic_string<unsigned short> s;
  auto p = f(s);
  char c = 0;
  if (s.size())
    c = *p;
  delete[] p;
  return c;
}


With -O2

copy.cc: In function 'int main()':
copy.cc:18:9: warning: array subscript 0 is outside array bounds of 'short
unsigned int [0]' [-Warray-bounds]
   18 |     c = *p;
      |         ^~
In function 'T* f(const std::__cxx11::basic_string<_CharT>&) [with T = short
unsigned int]',
    inlined from 'int main()' at copy.cc:15:13:
copy.cc:7:12: note: object of size 0 allocated by 'operator new []'
    7 |   auto p = new T[n];
      |            ^~~~~~~~


This is ridiculous. The array subscript is guarded by the same length as the
array. GCC manages to use the string length to determine the allocation size,
but can't use it to confirm the conditional read doesn't happen.


Referenced Bugs:

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

[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.3

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Likely a similar issue as PR104966, avoid relying on memory CSE across a call
to 'new'.

[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In this case s.size() reads a local variable that can't be altered by new.

[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
It looks like an escape analysis limitation.  With this simpler test case using
different types to rule out aliasing assumptions:

#include <string>

int main()
{
  std::basic_string<short> s;
  auto p = new int[s.size ()]{ };
  char c = 0;
  if (s.size())
    c = *p;
  delete[] p;
  return c;
}

pr104965.C:9:9: warning: array subscript 0 is outside array bounds of ‘void
[0]’ [-Warray-bounds]
    9 |     c = *p;
      |         ^~
pr104965.C:6:34: note: object of size 0 allocated by ‘operator new []’
    6 |   auto p = new short[s.size ()]{ };
      |                                  ^

One of the stores to the local s escapes its address which is then assumed to
have been clobbered by operator new:

  <bb 2> [local count: 1073741824]:
  s ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&s] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&s]._M_p = &s.D.33279._M_local_buf;
  s._M_string_length = 0;
  MEM[(char_type &)&s + 16] = 0;
  _5 = operator new [] (0);

  <bb 3> [local count: 1073741824]:
  _10 = s._M_string_length;
  if (_10 != 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 536870913]:
  _1 = MEM[(int *)_5];
  c_6 = (char) _1;

[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the missed optimization is recorded as either PR 79349 or PR 103827.

[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug middle-end/104965] [11/12/13 Regression] Yet another -Warray-bounds false positive

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Last reconfirmed|                            |2022-7-26

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Re-confirmed.  Didn't we change libstdc++ to not expect CSE around new?

[Bug middle-end/104965] [11/12/13 Regression] Yet another -Warray-bounds false positive

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

[Bug middle-end/104965] [11/12/13 Regression] Yet another -Warray-bounds false positive

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> Re-confirmed.  Didn't we change libstdc++ to not expect CSE around new?

I don't think that's valid, is it?

[Bug middle-end/104965] [11/12/13/14 Regression] Yet another -Warray-bounds false positive

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.