[PATCH RESEND] 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.

Signed-off-by: Benjamin Kramer <redacted>
---
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(-)

diff --git a/compat/bswap.h b/compat/bswap.h
index 279e0b4..f3b8c44 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h

@@ -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; })
 

-- 
1.6.5.3.149.g9aa3

Benjamin Kramer [off-list ref] writes:

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