[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy

[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93745
         Resolution|---                         |INVALID

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
Just to clarify, since I keep forgetting this myself.  The memmove -> memcpy
transformation for the test case isn't viable in GCC because the middle end
doesn't distinguish between the C test case in comment #3 and the following
valid C++ equivalent that changes the dynamic type of i[0] from int to float:

  void* operator new (__SIZE_TYPE__, void *p) { return p; }

  void foo(int* i, const float* f)
  {
    // i[0] = f[0];          // in C implies i != f
    new (&i[0]) float (f[0]);    // in C++ doesn't rule out that i == f
    __builtin_memmove(i, f, 1024*1024);
  }

(pr93745 discusses the same limitation.)

But even if GCC could make the assumption that i != f, it still wouldn't be
safe to transform he memmove call to memcpy because the overlap between the two
arrays could be inexact, as in:

  void bar (void)
  {
    float *p = new float[1024 * 1024 + 1]{ };
    foo ((int*)p, p + 1);
  }

With that, I think this report can be resolved.