PATCH to add xmemdup to libiberty

[Jeffrey A Law]

  In message < 19990908090610.B28798@elmo.cygnus.com >you write:
  > On Wed, Sep 08, 1999 at 11:27:04AM +0200, Marc Espie wrote:
  > > In article < 199909072040.QAA29321@havoc.gtf.org > you write:
  > > >PTR
  > > >xmemdup (input, copy_size, alloc_size)
  > > >  const PTR input;
  > > >  size_t copy_size;
  > > >  size_t alloc_size;
  > > >{
  > > >  PTR output = xcalloc (1, alloc_size);
  > > >  memcpy (output, input, copy_size);
  > > >  return output;
  > > >}
  > 
  > To pick some nits, given memcpy returns the argument, you can do:
  > 
  > {
  >   PTR output = xcalloc (1, alloc_size);
  >   return (memcpy (output, input, copy_size));
  > }
  > 
  > Though of course there might be some system out there that didn't implement
  > memcpy correctly.
There's a subtle bug in most older versions of gcc for targets which have
different conventions for normal calls vs library calls.

As I'm sure you remember when we determine the return type of a libcall we do
not have type information -- just a mode.  Now consider a port which returns
pointers differently than integers, but in which pointers are int are the
same size.

If we call memcpy via the libcall interface (like all releases up to and
including egcs-1.1.1), then the caller may expect the return value in one
register, while memcpy actually returned it in a different register.  And
we lose.

This is what prompted revamping of much of the code to emit calls to the mem*
functions to avoid the libcall code.

As for micro-optimizing, I seriously doubt it's worth anyone's time to think
about for this routine.  We've got better things to do than optimize a routine
that is so far off the critical path it isn't funny.

jeff