# [PATCH RESEND] Explicitly truncate bswap operand to uint32_t 2 messages from 2009-11-18 to 2009-11-23. Participants: Benjamin Kramer, Junio C Hamano. Thread: https://gitlist.dev/t/21661 ## Benjamin Kramer, 2009-11-18 13:53 Subject: [PATCH RESEND] Explicitly truncate bswap operand to uint32_t Message-ID: <4B03FC57.5000506@googlemail.com> URL: https://gitlist.dev/e/4B03FC57.5000506%40googlemail.com ``` 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 --- 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 ``` ## Junio C Hamano, 2009-11-23 00:16 Subject: Re: [PATCH RESEND] Explicitly truncate bswap operand to uint32_t Message-ID: <7vfx86aydh.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vfx86aydh.fsf%40alter.siamese.dyndns.org In-Reply-To: <4B03FC57.5000506@googlemail.com> ``` Benjamin Kramer 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 > --- > 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. ```