reassign 561249 libc6-dev thanks On Wed, Dec 16, 2009 at 10:54:21AM +0100, Aurelien Jarno wrote: > Eric Estievenart a écrit : > > The bug may be rather in libc6-dev, which defines: > > htons to __bswap16 if optimize && little endian, > > and __bswap16 in bits/byteswap.h > > # define __bswap_16(x) \ > > (__extension__ > > \ > > ({ register unsigned short int __v, __x = (x); > > \ > > if (__builtin_constant_p (__x)) > > \ > > __v = __bswap_constant_16 (__x); > > \ > > else > > \ > > __asm__ ("rorw $8, %w0" > > \ > > : "=r" (__v) > > \ > > : "0" (__x) > > \ > > : "cc"); > > \ > > __v; })) > > I'm not expert enough with gcc inline assembly to guess what the exact > > problem is, but it is definitely in this macro or the way gcc handles it, > > but since gcc <= 4.2 noes not show any warning in optimize it, I'd rather > > think it is a gcc (4.3 & 4.4) regression > > The problem is not the asm code, but actually the shift that comes from > __bswap_constant_16(). The problem can be reproduced with this simple code: > > #include <stdint.h> > > void test () > { > uint16_t s = 123; > uint16_t t = (s & 0xff) << 8; > uint16_t u = ((uint8_t)s) << 8; > } > > It looks like the << operator implicitely convert the value to int. I > haven't checked the standards about that.
Any arithmetic operation causes promotion of the operands from unsigned short to int first. So the warning is correct. Falk -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309153209.ga15...@minet.uni-jena.de