From: Eliav Farber <farbere@amazon.com>
To: <gregkh@linuxfoundation.org>, <jdike@addtoit.com>,
<richard@nod.at>, <anton.ivanov@cambridgegreys.com>,
<dave.hansen@linux.intel.com>, <luto@kernel.org>,
<peterz@infradead.org>, <tglx@linutronix.de>, <mingo@redhat.com>,
<bp@alien8.de>, <x86@kernel.org>, <hpa@zytor.com>,
<tony.luck@intel.com>, <qiuxu.zhuo@intel.com>,
<james.morse@arm.com>, <rric@kernel.org>, <airlied@linux.ie>,
<daniel@ffwll.ch>, <maarten.lankhorst@linux.intel.com>,
<mripard@kernel.org>, <tzimmermann@suse.de>,
<robdclark@gmail.com>, <sean@poorly.run>, <jdelvare@suse.com>,
<linux@roeck-us.net>, <linus.walleij@linaro.org>,
<dmitry.torokhov@gmail.com>, <maz@kernel.org>, <wens@csie.org>,
<jernej.skrabec@gmail.com>, <agk@redhat.com>,
<snitzer@redhat.com>, <dm-devel@redhat.com>,
<davem@davemloft.net>, <kuba@kernel.org>,
<mcoquelin.stm32@gmail.com>, <krzysztof.kozlowski@canonical.com>,
<malattia@linux.it>, <hdegoede@redhat.com>,
<mgross@linux.intel.com>, <jejb@linux.ibm.com>,
<martin.petersen@oracle.com>, <sakari.ailus@linux.intel.com>,
<clm@fb.com>, <josef@toxicpanda.com>, <dsterba@suse.com>,
<jack@suse.com>, <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<dushistov@mail.ru>, <luc.vanoostenryck@gmail.com>,
<rostedt@goodmis.org>, <pmladek@suse.com>,
<senozhatsky@chromium.org>, <andriy.shevchenko@linux.intel.com>,
<linux@rasmusvillemoes.dk>, <minchan@kernel.org>,
<ngupta@vflare.org>, <akpm@linux-foundation.org>,
<yoshfuji@linux-ipv6.org>, <dsahern@kernel.org>,
<pablo@netfilter.org>, <kadlec@netfilter.org>, <fw@strlen.de>,
<jmaloy@redhat.com>, <ying.xue@windriver.com>, <shuah@kernel.org>,
<willy@infradead.org>, <farbere@amazon.com>, <sashal@kernel.org>,
<quic_akhilpo@quicinc.com>, <ruanjinjie@huawei.com>,
<David.Laight@ACULAB.COM>, <herve.codina@bootlin.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-um@lists.infradead.org>,
<linux-edac@vger.kernel.org>, <amd-gfx@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
<linux-arm-msm@vger.kernel.org>,
<freedreno@lists.freedesktop.org>, <linux-hwmon@vger.kernel.org>,
<linux-input@vger.kernel.org>, <linux-sunxi@lists.linux.dev>,
<linux-media@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<platform-driver-x86@vger.kernel.org>,
<linux-scsi@vger.kernel.org>, <linux-staging@lists.linux.dev>,
<linux-btrfs@vger.kernel.org>, <linux-ext4@vger.kernel.org>,
<linux-sparse@vger.kernel.org>, <linux-mm@kvack.org>,
<netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>,
<tipc-discussion@lists.sourceforge.net>,
<linux-kselftest@vger.kernel.org>, <stable@vger.kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Jens Axboe <axboe@kernel.dk>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Mateusz Guzik <mjguzik@gmail.com>,
"Pedro Falcato" <pedro.falcato@gmail.com>
Subject: [PATCH 19/19 5.15.y] minmax.h: remove some #defines that are only expanded once
Date: Thu, 2 Oct 2025 20:47:33 +0000 [thread overview]
Message-ID: <20251002204733.35652-20-farbere@amazon.com> (raw)
In-Reply-To: <20251002204733.35652-1-farbere@amazon.com>
From: David Laight <David.Laight@ACULAB.COM>
[ Upstream commit 2b97aaf74ed534fb838d09867d09a3ca5d795208 ]
The bodies of __signed_type_use() and __unsigned_type_use() are much the
same size as their names - so put the bodies in the only line that expands
them.
Similarly __signed_type() is defined separately for 64bit and then used
exactly once just below.
Change the test for __signed_type from CONFIG_64BIT to one based on gcc
defined macros so that the code is valid if it gets used outside of a
kernel build.
Link: https://lkml.kernel.org/r/9386d1ebb8974fbabbed2635160c3975@AcuMS.aculab.com
Signed-off-by: David Laight <david.laight@aculab.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Mateusz Guzik <mjguzik@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Pedro Falcato <pedro.falcato@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
include/linux/minmax.h | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/linux/minmax.h b/include/linux/minmax.h
index 2bbdd5b5e07e..eaaf5c008e4d 100644
--- a/include/linux/minmax.h
+++ b/include/linux/minmax.h
@@ -46,10 +46,8 @@
* comparison, and these expressions only need to be careful to not cause
* warnings for pointer use.
*/
-#define __signed_type_use(ux) (2 + __is_nonneg(ux))
-#define __unsigned_type_use(ux) (1 + 2 * (sizeof(ux) < 4))
#define __sign_use(ux) (is_signed_type(typeof(ux)) ? \
- __signed_type_use(ux) : __unsigned_type_use(ux))
+ (2 + __is_nonneg(ux)) : (1 + 2 * (sizeof(ux) < 4)))
/*
* Check whether a signed value is always non-negative.
@@ -57,7 +55,7 @@
* A cast is needed to avoid any warnings from values that aren't signed
* integer types (in which case the result doesn't matter).
*
- * On 64-bit any integer or pointer type can safely be cast to 'long'.
+ * On 64-bit any integer or pointer type can safely be cast to 'long long'.
* But on 32-bit we need to avoid warnings about casting pointers to integers
* of different sizes without truncating 64-bit values so 'long' or 'long long'
* must be used depending on the size of the value.
@@ -66,12 +64,12 @@
* them, but we do not use s128 types in the kernel (we do use 'u128',
* but they are handled by the !is_signed_type() case).
*/
-#ifdef CONFIG_64BIT
- #define __signed_type(ux) long
+#if __SIZEOF_POINTER__ == __SIZEOF_LONG_LONG__
+#define __is_nonneg(ux) statically_true((long long)(ux) >= 0)
#else
- #define __signed_type(ux) typeof(__builtin_choose_expr(sizeof(ux) > 4, 1LL, 1L))
+#define __is_nonneg(ux) statically_true( \
+ (typeof(__builtin_choose_expr(sizeof(ux) > 4, 1LL, 1L)))(ux) >= 0)
#endif
-#define __is_nonneg(ux) statically_true((__signed_type(ux))(ux) >= 0)
#define __types_ok(ux, uy) \
(__sign_use(ux) & __sign_use(uy))
--
2.47.3
prev parent reply other threads:[~2025-10-03 7:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 20:47 [PATCH 00/19 5.15.y] Backport minmax.h updates from v6.17-rc7 Eliav Farber
2025-10-02 20:47 ` [PATCH 01/19 5.15.y] minmax: add in_range() macro Eliav Farber
2025-10-02 20:47 ` [PATCH 02/19 5.15.y] minmax: Introduce {min,max}_array() Eliav Farber
2025-10-02 20:47 ` [PATCH 03/19 5.15.y] minmax: deduplicate __unconst_integer_typeof() Eliav Farber
2025-10-02 20:47 ` [PATCH 04/19 5.15.y] minmax: fix indentation of __cmp_once() and __clamp_once() Eliav Farber
2025-10-02 20:47 ` [PATCH 05/19 5.15.y] minmax: avoid overly complicated constant expressions in VM code Eliav Farber
2025-10-02 20:47 ` [PATCH 06/19 5.15.y] minmax: make generic MIN() and MAX() macros available everywhere Eliav Farber
2025-10-02 20:47 ` [PATCH 07/19 5.15.y] minmax: add a few more MIN_T/MAX_T users Eliav Farber
2025-10-02 20:47 ` [PATCH 08/19 5.15.y] minmax: simplify and clarify min_t()/max_t() implementation Eliav Farber
2025-10-02 20:47 ` [PATCH 09/19 5.15.y] minmax: simplify min()/max()/clamp() implementation Eliav Farber
2025-10-02 20:47 ` [PATCH 10/19 5.15.y] minmax: don't use max() in situations that want a C constant expression Eliav Farber
2025-10-02 20:47 ` [PATCH 11/19 5.15.y] minmax: improve macro expansion and type checking Eliav Farber
2025-10-02 20:47 ` [PATCH 12/19 5.15.y] minmax: fix up min3() and max3() too Eliav Farber
2025-10-02 20:47 ` [PATCH 13/19 5.15.y] minmax.h: add whitespace around operators and after commas Eliav Farber
2025-10-02 20:47 ` [PATCH 14/19 5.15.y] minmax.h: update some comments Eliav Farber
2025-10-02 20:47 ` [PATCH 15/19 5.15.y] minmax.h: reduce the #define expansion of min(), max() and clamp() Eliav Farber
2025-10-02 20:47 ` [PATCH 16/19 5.15.y] minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() Eliav Farber
2025-10-02 20:47 ` [PATCH 17/19 5.15.y] minmax.h: move all the clamp() definitions after the min/max() ones Eliav Farber
2025-10-02 20:47 ` [PATCH 18/19 5.15.y] minmax.h: simplify the variants of clamp() Eliav Farber
2025-10-02 20:47 ` Eliav Farber [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251002204733.35652-20-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=David.Laight@ACULAB.COM \
--cc=Jason@zx2c4.com \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=arnd@kernel.org \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=clm@fb.com \
--cc=coreteam@netfilter.org \
--cc=dan.carpenter@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dm-devel@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsahern@kernel.org \
--cc=dsterba@suse.com \
--cc=dushistov@mail.ru \
--cc=freedreno@lists.freedesktop.org \
--cc=fw@strlen.de \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=hdegoede@redhat.com \
--cc=herve.codina@bootlin.com \
--cc=hpa@zytor.com \
--cc=jack@suse.com \
--cc=james.morse@arm.com \
--cc=jdelvare@suse.com \
--cc=jdike@addtoit.com \
--cc=jejb@linux.ibm.com \
--cc=jernej.skrabec@gmail.com \
--cc=jmaloy@redhat.com \
--cc=josef@toxicpanda.com \
--cc=kadlec@netfilter.org \
--cc=krzysztof.kozlowski@canonical.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-um@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@roeck-us.net \
--cc=lorenzo.stoakes@oracle.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=luto@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=malattia@linux.it \
--cc=martin.petersen@oracle.com \
--cc=maz@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mgross@linux.intel.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=mripard@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=ngupta@vflare.org \
--cc=pablo@netfilter.org \
--cc=pedro.falcato@gmail.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=qiuxu.zhuo@intel.com \
--cc=quic_akhilpo@quicinc.com \
--cc=richard@nod.at \
--cc=robdclark@gmail.com \
--cc=rostedt@goodmis.org \
--cc=rric@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=sakari.ailus@linux.intel.com \
--cc=sashal@kernel.org \
--cc=sean@poorly.run \
--cc=senozhatsky@chromium.org \
--cc=shuah@kernel.org \
--cc=snitzer@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tipc-discussion@lists.sourceforge.net \
--cc=tony.luck@intel.com \
--cc=tytso@mit.edu \
--cc=tzimmermann@suse.de \
--cc=wens@csie.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=ying.xue@windriver.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.