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
