[Bug tree-optimization/107751] [11/12/13 regression] False positive -Wmaybe-uninitialized at -O0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase (removes the templates, also now able to compile as C):
> typedef const int T1;
> typedef const int T2;
> void std_equal(T1* a1, T1* a2, T2* b1);
> void f() {
>     int a[3] = {1, 2, 3};
>     T1* x    = a;
>     T2* y    = a;
>     std_equal(x, x+3, y);
> }

It's also odd we diagnose x + 3 but not x + 2.  We're using
ao_ref_init_from_ptr_and_size but that's not a good measure,
esp. for

  /* Do not warn if the access is zero size or if it's fully outside
     the object.  */
  poly_int64 decl_size;
  if (known_size_p (ref.size)
      && known_eq (ref.max_size, ref.size)
      && (known_eq (ref.size, 0)
          || known_le (ref.offset + ref.size, 0)))
    return NULL_TREE;

also given that this function doesn't do a good job at gettting at &a for
the IL at -O0 which is

  <bb 2> :
  a[0] = 1;
  a[1] = 2;
  a[2] = 3;
  x_6 = &a;
  y_7 = &a;
  _1 = x_6 + 8;
  std_equal (x_6, _1, y_7);

note that a function receiving x + O can adjust this pointer before reading
from it so using [x+O, +INF] as access range to find initialization isn't
the best thing to do.