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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
