This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > gets compiled with -O2 -m32 by gcc 2.96 (but similarly by egcs 1.1.2) into: > > foo: save %sp, -224, %sp > > sethi %hi(.LLC0+1), %o0 > > or %o0, %lo(.LLC0+1), %o0 > > add %o0, -1, %o5 > > sub %o0, %o5, %o0 > > cmp %o0, 1 > > bne .LL145 > > mov %i0, %o0 > > mov 115, %o1 > > [...] > > This certainly is a SPARC problem. Maybe some other platform, but not > x86 and presumably not m68k. Are you sure about this? If I do on i686: mkdir bits touch bits/string.h cat > test.c <<EOF #include <string.h> void foo(char *p) { strcpy(p, "strn"); } EOF gcc -S -O2 -o test1.s test.c gcc -S -O2 -o test2.s test.c -D__NO_STRING_INLINES test1.s is far longer and slower than test2.s (9 vs. 47 insns). The fact that you're not normaly seeing it seems that i386 string.h defines its own versions of the problematic glibc inlines. BTW: I was posting a bugfix for bits/errno.h yesterday as well, could you look at it and if it is ok commit it? Thanks. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |