* [PATCH] shut up warnings in bits/string2.h @ 1999-12-07 13:02 Jakub Jelinek 1999-12-07 18:41 ` Richard Henderson 1999-12-07 23:41 ` Ulrich Drepper 0 siblings, 2 replies; 6+ messages in thread From: Jakub Jelinek @ 1999-12-07 13:02 UTC (permalink / raw) To: drepper; +Cc: libc-hacker Hi! This patch shuts up gcc 2.96 warnings about long switch expressions not converted to int. BTW: I've seen pretty bad code as result of the string2.h inlines on sparc, while -D__NO_STRING_INLINES gave me much better code as the compiler did the job. I'll investigate why that happens and for which functions and submit a sparc string.h which will disable those inlines from string2.h which result in bad code. How does it work on other architectures? 1999-12-07 Jakub Jelinek <jakub@redhat.com> * string/bits/string2.h (__memset_gc, __mempcpy_small, __strcpy_small, __stpcpy_small): Cast switch expressions to int to shut up compiler warnings. --- string/bits/string2.h.jj12 Thu Oct 14 21:29:59 1999 +++ string/bits/string2.h Mon Dec 6 12:18:37 1999 @@ -118,7 +118,7 @@ __STRING2_COPY_TYPE (8); __uint8_t __c = (__uint8_t) (c); \ \ /* This `switch' statement will be removed at compile-time. */ \ - switch (n) \ + switch ((unsigned int)n) \ { \ case 15: \ __u->__ui = __c * 0x01010101; \ @@ -230,7 +230,7 @@ __mempcpy_small (void *__dest1, unsigned char __uc; unsigned char __c; } *__u = __dest1; - switch (__srclen) + switch ((unsigned int)__srclen) { case 1: __u->__c = __src0_1; @@ -332,7 +332,7 @@ __mempcpy_small (void *__dest, char __sr __STRING2_COPY_ARR7 __sca7; __STRING2_COPY_ARR8 __sca8; } *__u = __dest; - switch (__srclen) + switch ((unsigned int)__srclen) { case 1: __u->__c = __src1; @@ -405,7 +405,7 @@ __strcpy_small (char *__dest, __uint16_t __usi; unsigned char __uc; } *__u = (void *) __dest; - switch (__srclen) + switch ((unsigned int)__srclen) { case 1: __u->__uc = '\0'; @@ -498,7 +498,7 @@ __strcpy_small (char *__dest, __STRING2_COPY_ARR7 __sca7; __STRING2_COPY_ARR8 __sca8; } *__u = (void *) __dest; - switch (__srclen) + switch ((unsigned int)__srclen) { case 1: __u->__c = '\0'; @@ -565,7 +565,7 @@ __stpcpy_small (char *__dest, unsigned char __uc; char __c; } *__u = (void *) __dest; - switch (__srclen) + switch ((unsigned int)__srclen) { case 1: __u->__uc = '\0'; @@ -662,7 +662,7 @@ __stpcpy_small (char *__dest, __STRING2_COPY_ARR7 __sca7; __STRING2_COPY_ARR8 __sca8; } *__u = (void *) __dest; - switch (__srclen) + switch ((unsigned int)__srclen) { case 1: __u->__c = '\0'; 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) ___________________________________________________________________ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] shut up warnings in bits/string2.h 1999-12-07 13:02 [PATCH] shut up warnings in bits/string2.h Jakub Jelinek @ 1999-12-07 18:41 ` Richard Henderson 1999-12-07 23:41 ` Ulrich Drepper 1 sibling, 0 replies; 6+ messages in thread From: Richard Henderson @ 1999-12-07 18:41 UTC (permalink / raw) To: Jakub Jelinek; +Cc: drepper, libc-hacker On Tue, Dec 07, 1999 at 10:08:11PM +0100, Jakub Jelinek wrote: > * string/bits/string2.h (__memset_gc, __mempcpy_small, __strcpy_small, > __stpcpy_small): Cast switch expressions to int to shut up compiler > warnings. The patch is wrong Jakub. Suppose you have a string of length 0x1_0000_0001. You will truncate this to 1 and do the wrong thing. I know you are trying to silence the extra warnings from gcc's -Wtraditional, but there's nothing to be done about it except possibly nuking it from the compiler. r~ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] shut up warnings in bits/string2.h 1999-12-07 13:02 [PATCH] shut up warnings in bits/string2.h Jakub Jelinek 1999-12-07 18:41 ` Richard Henderson @ 1999-12-07 23:41 ` Ulrich Drepper 1999-12-08 0:22 ` Jakub Jelinek 1 sibling, 1 reply; 6+ messages in thread From: Ulrich Drepper @ 1999-12-07 23:41 UTC (permalink / raw) To: Jakub Jelinek; +Cc: libc-hacker Jakub Jelinek <jakub@redhat.com> writes: > This patch shuts up gcc 2.96 warnings about long switch expressions not > converted to int. Well, rth commented that this might fail for long strings. But those strings must be string constants, not actual strings. And gcc (nor any other compiler) will have support for strings of more than 2^32 character in length. So it should be possible to apply the patch. > How does it work on other architectures? Which functions? The generic functions should perform quite good. The copying of constant strings work by moving immedate values which is much faster. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] shut up warnings in bits/string2.h 1999-12-07 23:41 ` Ulrich Drepper @ 1999-12-08 0:22 ` Jakub Jelinek 1999-12-08 0:34 ` Ulrich Drepper 0 siblings, 1 reply; 6+ messages in thread From: Jakub Jelinek @ 1999-12-08 0:22 UTC (permalink / raw) To: Ulrich Drepper; +Cc: libc-hacker On Tue, Dec 07, 1999 at 11:38:43PM -0800, Ulrich Drepper wrote: > Jakub Jelinek <jakub@redhat.com> writes: > > > This patch shuts up gcc 2.96 warnings about long switch expressions not > > converted to int. > > Well, rth commented that this might fail for long strings. But those > strings must be string constants, not actual strings. And gcc (nor > any other compiler) will have support for strings of more than 2^32 > character in length. So it should be possible to apply the patch. All the inlines where I changed this are invoked from macros which guard it by something like this: __builtin_constant_p (n) && (n) <= 16 where the length limit is 16 or 8 as far as I could see, so I don't see how that could be a problem (the only problematic thing could be say memcpy(p, "string", -4) because then n is builtin constant and is <= 16, but that should be guarded by __builtin_constant_p (n) && (n) <= 16U ). > > > How does it work on other architectures? > > Which functions? The generic functions should perform quite good. > The copying of constant strings work by moving immedate values which > is much faster. E.g. #include <string.h> void foo(char *p) { strcpy(p, "strn"); } 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 mov 116, %o2 mov 114, %o3 mov 110, %o4 stb %o1, [%fp-32] stb %g0, [%fp-31] stb %o1, [%fp-24] stb %g0, [%fp-23] stb %o1, [%fp-48] stb %o2, [%fp-47] stb %g0, [%fp-46] stb %o1, [%fp-40] stb %o2, [%fp-39] stb %g0, [%fp-38] stb %o1, [%fp-64] stb %o2, [%fp-63] stb %o3, [%fp-62] stb %g0, [%fp-61] stb %o1, [%fp-56] stb %o2, [%fp-55] stb %o3, [%fp-54] stb %g0, [%fp-53] stb %o1, [%fp-80] stb %o2, [%fp-79] stb %o3, [%fp-78] stb %o4, [%fp-77] stb %g0, [%fp-76] stb %o1, [%fp-72] stb %o2, [%fp-71] stb %o3, [%fp-70] stb %o4, [%fp-69] stb %g0, [%fp-68] ldub [%o5+5], %o7 mov %o1, %l0 stb %o1, [%fp-96] stb %o2, [%fp-95] stb %o3, [%fp-94] stb %o4, [%fp-93] stb %g0, [%fp-92] stb %g0, [%fp-91] stb %o1, [%fp-88] stb %o2, [%fp-87] stb %o3, [%fp-86] stb %o4, [%fp-85] stb %g0, [%fp-84] stb %g0, [%fp-83] stb %o1, [%fp-112] stb %o2, [%fp-111] stb %o3, [%fp-110] stb %o4, [%fp-109] stb %g0, [%fp-108] stb %o7, [%fp-107] stb %g0, [%fp-106] stb %o1, [%fp-104] stb %o2, [%fp-103] stb %o3, [%fp-102] stb %o4, [%fp-101] stb %g0, [%fp-100] stb %o7, [%fp-99] stb %g0, [%fp-98] ldub [%o5+6], %l1 mov %o2, %g3 ldub [%fp-68], %o0 stb %o1, [%fp-120] stb %o2, [%fp-119] stb %o3, [%fp-118] stb %o4, [%fp-117] stb %o7, [%fp-115] stb %l1, [%fp-114] mov %o3, %g2 mov %o4, %o5 stb %o0, [%i0+4] stb %l0, [%i0] stb %g3, [%i0+1] stb %g2, [%i0+2] stb %o5, [%i0+3] stb %o1, [%fp-128] stb %o2, [%fp-127] stb %o3, [%fp-126] stb %o4, [%fp-125] stb %g0, [%fp-124] stb %o7, [%fp-123] stb %l1, [%fp-122] stb %g0, [%fp-121] stb %g0, [%fp-116] b .LL144 stb %g0, [%fp-113] .LL145: mov %o5, %o1 call memcpy, 0 mov 5, %o2 .LL144: ret restore while compiling it with the same compiler with -O2 -D__NO_STRING_INLINES turns into (and similarly with egcs 1.1.2): foo: sethi %hi(.LLC0), %g2 ldub [%g2+%lo(.LLC0)], %g3 or %g2, %lo(.LLC0), %g2 stb %g3, [%o0] ldub [%g2+1], %g3 stb %g3, [%o0+1] ldub [%g2+2], %o1 stb %o1, [%o0+2] ldub [%g2+3], %g3 stb %g3, [%o0+3] ldub [%g2+4], %o1 retl stb %o1, [%o0+4] I haven't yet investigated what's the problem, but some string2.h inlines work as expected (e.g. memset). 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) ___________________________________________________________________ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] shut up warnings in bits/string2.h 1999-12-08 0:22 ` Jakub Jelinek @ 1999-12-08 0:34 ` Ulrich Drepper 1999-12-08 7:56 ` Jakub Jelinek 0 siblings, 1 reply; 6+ messages in thread From: Ulrich Drepper @ 1999-12-08 0:34 UTC (permalink / raw) To: Jakub Jelinek; +Cc: libc-hacker Jakub Jelinek <jakub@redhat.com> writes: > All the inlines where I changed this are invoked from macros which guard it > by something like this: > __builtin_constant_p (n) && (n) <= 16 Yep. > 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. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] shut up warnings in bits/string2.h 1999-12-08 0:34 ` Ulrich Drepper @ 1999-12-08 7:56 ` Jakub Jelinek 0 siblings, 0 replies; 6+ messages in thread From: Jakub Jelinek @ 1999-12-08 7:56 UTC (permalink / raw) To: Ulrich Drepper; +Cc: libc-hacker > > 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) ___________________________________________________________________ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-12-08 7:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-12-07 13:02 [PATCH] shut up warnings in bits/string2.h Jakub Jelinek 1999-12-07 18:41 ` Richard Henderson 1999-12-07 23:41 ` Ulrich Drepper 1999-12-08 0:22 ` Jakub Jelinek 1999-12-08 0:34 ` Ulrich Drepper 1999-12-08 7:56 ` Jakub Jelinek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).