This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: memcpy(p,p,len)
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Mark Mielke <mark at mark dot mielke dot cc>, Jan-Benedict Glaw <jbglaw at lug-owl dot de>, Joakim Tjernlund <joakim dot tjernlund at transmode dot se>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 30 Apr 2010 17:06:58 -0700
- Subject: Re: memcpy(p,p,len)
- References: <OFD9AE9802.614419A7-ONC1257715.004D817C-C1257715.004DA923@transmode.se> <20100430141042.GB19632@lug-owl.de> <OFBE8D441E.412B9092-ONC1257715.004E073D-C1257715.004E3DFA@transmode.se> <20100430142521.GC19632@lug-owl.de> <4BDAE989.1020807@mark.mielke.cc> <20100430150512.GT25881@synopsys.com> <y2g84fc9c001004300829vf5be2234h19c40508fecdabd3@mail.gmail.com>
On Fri, Apr 30, 2010 at 08:29:19AM -0700, Richard Guenther wrote:
> On Fri, Apr 30, 2010 at 5:05 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
> > On Fri, Apr 30, 2010 at 07:30:33AM -0700, Mark Mielke wrote:
> >> Just a quick comment than Jan-Benedict's opinion is widely shared by the
> >> specification and by the Linux glibc manpage:
> >>
> >> DESCRIPTION
> >> ? ? ? ? The ?memcpy() ?function ?copies ?n bytes from memory area src to
> >> memory
> >> ? ? ? ? area dest. ?The memory areas should not overlap. ?Use memmove(3)
> >> if the
> >> ? ? ? ? memory areas do overlap.
> >>
> >> It doesn't matter if it sometimes works. Sometimes works programs are
> >> sometimes doesn't work programs. :-)
> >
> > The typical memcpy function will fail for overlapping but unequal memory
> > ranges, but will work for src == dst. ?Switching to memmove would degrade
> > performance, and that should only be done if there is an actual, rather
> > than a theoretical bug. ?Note that for this use, it's not possible (if
> > the program is valid) for the ranges to overlap but be unequal.
> >
> > Another alternative is that instead of using memcpy, a specialized
> > function could be used that has the required property (the glibc
> > memcpy does).
>
> Note that language semantics come in here as well. The middle-end
> assumes that when an assignment is not BLKmode that the RHS
> will be read before the lhs will be written. It does not assume so
> otherwise and the behavior is undefined for overlapping *p and *q
> if you do *p = *q. Thus it is up to the frontend to emit a call to
> memmove in this case (the C++ frontend got bitten by this and
> was fixed).
If the only possibilities are that p == q, or *p and *q do not overlap,
then
if (p != q)
memcpy(p, q, n);
would be cheaper than memmove, which has to choose between forward and
backward copying to handle overlap. However, some memcpy implementations
(including the one in glibc) will do the right thing even without the
test.
If structure copying suddenly produces memmove calls, that would not
be good.