Explicitly truncate bswap operand to uint32_t
PATCH RESEND 1/1 Explicitly truncate bswap operand to uint32_t
There are some places in git where a long is passed to htonl/ntohl. llvm doesn't support matching operands of different bitwidths intentionally. This patch fixes the build with llvm-gcc (and clang) on x86_64.
---
Any comments on this patch?
See also:
* http://llvm.org/bugs/show_bug.cgi?id=3373
* http://lkml.org/lkml/2009/1/23/261
compat/bswap.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
compat/bswap.h +1 -1
@@ -24,7 +24,7 @@ static inline uint32_t default_swab32(uint32_t val)if (__builtin_constant_p (x)) { \ __res =default_swab32 (x); \ }else { \ - __asm__("bswap %0" :"=r" (__res) :"0" (x)); \ + __asm__("bswap %0" :"=r" (__res) :"0" ((uint32_t )(x))); \ } \ __res; })
Signature · 1 line
1.6.5.3.149.g9aa3
Quoted 7 lines · Benjamin Kramer
There are some places in git where a long is passed to htonl/ntohl. llvm doesn't support matching operands of different bitwidths intentionally. This patch fixes the build with llvm-gcc (and clang) on
x86_64.Signed-off-by Benjamin Kramer <[email protected]>---
Any comments on this patch?
My vague recollection is that the response was "we do not mind it per-se, unless it ends up in an ugly change; but we would prefer if you go fix your compiler", but maybe I read it on lkml not here?
Also my vague recollection is that the kernel folks took that patch in the end, so I think it is Ok for us to take this patch, too.