Sequent Dynix 4.4.2 problems with g++ compiler (w/fix suggested)

["Ronald F. Guilmette" <rfg at monkeys dot com>]

The g++ 2.95.2 compiler messes up badly on Dynix 4.4.2 (Sequent hardware)
when compiling some module or another in libio.

Basically, the g++ front end is just losing track of which member function
have been declared in a class.

I believe that I have tracked thsi down now.  The problem seems to derive
from the following call to bcopy in the file cp/class.c (at around line 1229):



                {
                  /* We know the last slot in the vector is empty
                     because we know that at this point there's room
                     for a new function.  */
                  bcopy ((PTR) &TREE_VEC_ELT (method_vec, slot),
                         (PTR) &TREE_VEC_ELT (method_vec, slot + 1),
                         (len - slot - 1) * sizeof (tree));
                  TREE_VEC_ELT (method_vec, slot) = NULL_TREE;
                }


The problem is that in this specific case, bcopy is being asked to copy one
region of memory to an overlapping region of memory.

Unfortunately, whoever implemented the C library bcopy() function for Dynix
4.4.2 didn't look closely enough at the original bcopy() man page from BSD
UNIX, and it appears the Dynix 4.4.2 bcopy() _does not_ properly handle
the case where the input and output regions overlap.

The solution is obvious... I need to stick a definition like:

    #  define bcopy(src,dst,len) memmove((dst),(src),(len))

in someplace.  I just haven't figured out where that should go yet.

The real soulution is probably to make the gcc/g++ configure script treat
Dynix 4.x.x as a special case... even though it has a bcopy() in its C
library, this should NOT be used for building gcc/g++, and thus, the
configure script should probably recognize the special case of Dynix
and then arrange to undef HAVE_BCOPY.