On Mon, 13 Mar 2000, Philipp Thomas wrote:
> * David S. Miller (davem@redhat.com) [20000310 10:31]:
>
> > +#include <linux/string.h>
>
> But that doesn't help when using current CVS gcc and it decides to generate
> a memcpy libcall as those places won't see the inlined versions from
> asm/string.h, at least not on ia32.
True statement. Here's a structure copy example from aic7xxx.c.
9035 #if 0
9036 p->sc = *sc;
9037 #else
9038 memcpy(&p->sc, sc, sizeof(*sc));
9039 #endif
If you take your hands off the wheel (don't tell the compiler exactly
what to do), new snapshots will generate a libcall instead of using
an internally defined inline memcpy() as it used to.
I can find no doc which states that the compiler must inline this type
of operation, and the (highly qualified) people I queried offline about
it agree that it's up to the compiler. If this is true, it means that
it's a coding bug to use this kind of construct in the kernel [1]. Or?
-Mike
1. even if you put memcpy() in a lib, nothing dictates that the compiler
can't call bcopy().. or a whole slew of libc functions for that matter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:23 EST