memcpy vs memmove and structure returns

Kaveh R. Ghazi ghazi@caip.rutgers.edu
Mon Apr 16 07:30:00 GMT 2001


 > 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



More information about the Gcc-patches mailing list