[Bug tree-optimization/92879] [10 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |alias
             Blocks|                            |56456

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning sees the IL below so it's doing the right thing.  GCC doesn't
"know" that operator new doesn't clobber this->m so it doesn't eliminate the
for loop.  Rewriting the loop like so avoids the warning and results in optimal
code equivalent to that emitted by Clang:

        for(int j=0;j<i;j++) new(p+j)int();

Unlike in LP64 where the range of the size argument to memset is [4,
8589934588], in ILP32 its range is VARYING (a 32-bit int converted to a 32-bit
unsigned), so the warning isn't issued.

Since in a ctor, the this pointer can be assumed not to have escaped (unless
proven otherwise from its body), I think the root cause is a limitation of the
aliasing machinery.

_GLOBAL__sub_I_a ()
{
  int i;
  int _2;
  void * _5;
  sizetype _6;
  sizetype _7;
  unsigned int _12;
  unsigned int _20;
  sizetype _21;

  <bb 2> [local count: 1073741824]:
  MEM[(struct  &)&a] ={v} {CLOBBER};
  a.m = 0;
  _5 = operator new [] (0);
  a.p = _5;
  _2 = a.m;                         <<< unnecessary: _2 must be 0
  if (_2 <= 0)
    goto <bb 4>; [11.00%]
  else
    goto <bb 3>; [89.00%]

  <bb 3> [local count: 955630224]:
  _20 = (unsigned int) _2;
  _12 = _20 + 4294967295;
  _6 = (sizetype) _12;
  _21 = (sizetype) _2;
  _7 = _21 * 4;
  __builtin_memset (_5, 0, _7);

  <bb 4> [local count: 1073741833]:
  return;

}


Referenced Bugs:

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