This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/39480] generated memcpy causes trouble in assignment
- From: "fpbeekhof at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Mar 2009 09:56:44 -0000
- Subject: [Bug c++/39480] generated memcpy causes trouble in assignment
- References: <bug-39480-14973@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #22 from fpbeekhof at gmail dot com 2009-03-18 09:56 -------
Subject: Re: generated memcpy causes trouble in assignment
jakub at gcc dot gnu dot org wrote:
> ------- Comment #20 from jakub at gcc dot gnu dot org 2009-03-18 09:10 -------
> So let's use memmove on alpha and let targets with sane memcpy not suffer just
> because of one dead architecture.
1) sane memcpy, by the standard, is unsafe.
2) alpha was just an example, I vaguely remember that similar problems
were found on x86 with certain mmx instructions, but don't remember the
details.
A better approach is to use memmove by default, and memcpy when you can
prove that it's safe; rather than assuming that a "non-dead"
architecture extends the standard.
Alternatively, the following should be safe too, in accordance with
comment #21:
Foo &operator=(const Foo &rhs)
{
if (this != &rhs)
memcpy(this, &rhs, sizeof(Foo));
}
But that introduces a branch instruction.
Another safe alternative is to do what is described in comment #12.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480