[Bug c++/39480] generated memcpy causes trouble in assignment

["jason at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #18 from jason at gcc dot gnu dot org  2009-03-18 03:29 -------
I can't imagine an implementation of memcpy that would break when the two
addresses are the same, it just doesn't work if one is offset but overlapping. 
So the valgrind warning is pedantically correct, but I think it doesn't
indicate a real safety issue.

I can reproduce the generated memcpy with trunk if I use the preprocessor
output from 4.2 adjusted for the changes in __is_pod/__is_empty.  It doesn't
appear when just compiling the testcase because the contents of HarrisPoint are
completely different (was there library ABI breakage between 4.2 and 4.3?)

The call comes from the front end in build_over_call, and that code is still
present.

However, it seems that emit_block_move_hints will also use memcpy if
move_by_pieces and movmem aren't suitable, so this is more than just a C++
issue.  For instance, if I comment out the emit_block_move_via_movemem case,
this C testcase uses memcpy, and it has no way to know whether or not the two
pointers are the same.

struct A
{
  int i[200];
};

struct A *p1, *p2;
void f()
{
  *p1 = *p2;
}


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480