[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||12.0

--- Comment #9 from Martin Sebor  ---
Today's trunk doesn't reproduce it but the warning is still issued with GCC 12
for a GCC 11 translation unit, so it must be some library change that's made it
go away.

[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #8 from Andrew Pinski  ---
(In reply to Derek Mauro from comment #0)
> This is strange issue that started appearing in gcc 10.1. It also seems to
> require -O3 and -std=gnu++11 (gnu++14 etc appear unaffected).

I can't reproduce this with r12-5457-g06be28f64a0b5bfc. So someone should do a
bisect to see when it was fixed.



(In reply to Egor Suvorov from comment #4)
> A possibly related example (also available at Godbolt:
> https://godbolt.org/z/P65dx1 )

This example is fixed with r12-5465-g911b633803dcbb298 (double checked).

[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #6)
> The example in comment #4 is due to the same problem/limitation in the
> optimizer.  The IL that triggers the warning is below:

I am going to fix this issue as part of PR 102216.

[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||alias
  Component|c++ |tree-optimization

--- Comment #6 from Martin Sebor  ---
The example in comment #4 is due to the same problem/limitation in the
optimizer.  The IL that triggers the warning is below:

   [local count: 1073741833]:
  MEM[(struct _Vector_impl_data *)] ={v} {CLOBBER};
  _32 = operator new (3);
  _27 = _32 + 3;  <<< _27
  *_32.x = 0;
  MEM[(struct S *)_32 + 1B].x = 0;
  MEM[(struct S *)_32 + 2B].x = 0;
  __cur_3 =   [(void *)_32 + 3B];   <<< same as _27
  if (__cur_3 != _27) <<< must be false
goto ; [82.57%]
  else
goto ; [17.43%]

   [local count: 797929761]:
  MEM[(struct S *)_32 + 3B] = 0;  <<< -Wstringop-overflow=
  goto ; [100.00%]

GCC doesn't fold the equality (_32 + 3 ==   [(void *)_32 + 3B]).

A simplified test case for that limitation is below:

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
struct S { char a[3]; };

void f (struct S *p)
{
  void *q0 = p + 1;
  void *q1 = p->a + sizeof *p;

  if (q0 != q1)   // not folded but should be
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)

void f (struct S * p)
{
  void * q1;
  void * q0;

   [local count: 1073741824]:
  q0_2 = p_1(D) + 3;
  q1_3 =   [(void *)p_1(D) + 3B];
  if (q0_2 != q1_3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}