[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <d0fadaa3-94d4-4600-8e92-a8fe5b0f141b@app.fastmail.com>
Date: Wed, 24 Jul 2024 13:03:09 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Anshuman Khandual" <anshuman.khandual@....com>,
linux-kernel@...r.kernel.org
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
"Yury Norov" <yury.norov@...il.com>,
"Rasmus Villemoes" <linux@...musvillemoes.dk>,
Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 1/2] uapi: Define GENMASK_U128
On Wed, Jul 24, 2024, at 12:31, Anshuman Khandual wrote:
> --- a/include/uapi/asm-generic/bitsperlong.h
> +++ b/include/uapi/asm-generic/bitsperlong.h
> @@ -28,4 +28,8 @@
> #define __BITS_PER_LONG_LONG 64
> #endif
>
> +#ifndef __BITS_PER_U128
> +#define __BITS_PER_U128 128
> +#endif
I would hope we don't need this definition. Not that it
hurts at all, but __BITS_PER_LONG_LONG was already kind
of pointless since we don't run on anything else and
__BITS_PER_U128 clearly can't have any other sensible
definition than a plain 128.
> #define __AC(X,Y) (X##Y)
> #define _AC(X,Y) __AC(X,Y)
> #define _AT(T,X) ((T)(X))
> +#define _AC128(X) ((unsigned __int128)(X))
I just tried using this syntax and it doesn't seem to do
what you expected. gcc silently truncates the constant
to a 64-bit value here, while clang fails the build.
See also https://godbolt.org/z/rzEqra7nY
https://stackoverflow.com/questions/63328802/unsigned-int128-literal-gcc
The __GENMASK_U128() macro however seems to work correctly
since you start out with a smaller number and then shift
it after the type conversion.
Arnd
Powered by blists - more mailing lists