This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: memcpy vs memmove and structure returns
- To: law at redhat dot com
- Subject: Re: memcpy vs memmove and structure returns
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Mon, 16 Apr 2001 10:30:32 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org
> From: law@redhat.com
>
> In message <200104141306.JAA25897@caip.rutgers.edu>you write:
> >
> > > I've checked in Loren's patch from March to the mainline and branch
> > > trees to fix a codegen regression on several platforms
> > > (execute/20010124-1.c).
> > >
> > > This is step #1 (of 2) related to revamping how assignments work.
> > > The second part (still under construction) is designed to allow us
> > > to use memcpy for structure returns when we can prove it's safe.
> > >
> > > I've bootstrapped both PA32 and PA64 with this change on the gcc-3.0
> > > branch.
> > > * expr.h (enum libfunc_index): Add LTI_memmove.
> > > (memmove_libfunc): Define macro.
> > > * optabs.c (init_optabs): Initialize memmove_libfunc.
> > > * expr.c (expand_assignment): Use memmove_libfunc instead of
> > > memcpy_libfunc.
> >
> >
> > Are we considering svr3 platforms that are missing memmove?
>
> Are there any svr3 platforms that we still care about that don't
> have memmove? Is there an alternate function we can use to do
> copies on those platforms when the source & dest might overlap?
> jeff
The phrase: "that we still care about" probably means the answer is
no.
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions