Skip to contentSkip to conversation

Explicitly truncate bswap operand to uint32_t

PATCH RESEND In review Benjamin Kramer 2 participants 2 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

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
index 279e0b4..f3b8c44 100644
@@ -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
#1 lore raw
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.

---
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.