From: David Laight <David.Laight@ACULAB.COM>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
Linus Torvalds <torvalds@linux-foundation.org>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Nathan Chancellor <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Yury Norov <yury.norov@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@linaro.org>,
James Clark <james.clark@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Rikard Falkeborn <rikard.falkeborn@gmail.com>,
Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
Cc: "linux-sparse@vger.kernel.org" <linux-sparse@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"coresight@lists.linaro.org" <coresight@lists.linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 03/10] compiler.h: add is_const_true() and is_const_false()
Date: Wed, 4 Dec 2024 18:48:38 +0000 [thread overview]
Message-ID: <c617483816b54096ba4b30bea595da49@AcuMS.aculab.com> (raw)
In-Reply-To: <20241203-is_constexpr-refactor-v1-3-4e4cbaecc216@wanadoo.fr>
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> __builtin_constant_p() is known for not always being able to produce
> constant expression [1] which led to the introduction of
> __is_constexpr() [2]. Because of its dependency on
> __builtin_constant_p(), statically_true() suffers from the same
> issues.
No, they are testing different things.
>
> For example:
>
> void foo(int a)
> {
> /* fail on GCC */
> BUILD_BUG_ON_ZERO(statically_true(a));
>
> /* fail on both clang and GCC */
> static char arr[statically_true(a) ? 1 : 2];
> }
>
> Define a new is_const_true() and is_const_false() pair of macros
> which, by making use of __is_const_zero(), always produces a constant
> expression.
>
> Note that is_const_false() can not be directly defined as an alias to
> __is_const_zero(). Otherwise, it could yield some false positives on
> huge numbers because of a lost of precision when doing the (long) cast
> in __is_const_zero(). Example:
>
> is_const_false((u128)ULONG_MAX << BITS_PER_LONG)
>
> Furthermore, using the ! operator like this:
>
> #define is_const_true(x) __is_const_zero(!(x))
> #define is_const_false(x) __is_const_zero(!!(x))
>
> would yield a -Wint-in-bool-context compiler warning if the argument
> is not a boolean. Use the == and != operators instead.
>
> It should be noted that statically_true/false() are the only ones
> capable of folding tautologic expressions in which at least one on the
> operands is not a constant expression. For example:
>
> statically_true(true || var)
> statically_true(var == var)
> statically_false(var * 0)
> statically_false(var * 8 % 4)
>
> always evaluate to true, whereas all of these would be false under
> is_const_true/false() if var is not a constant expression [3].
>
> For this reason, usage of const_true/false() should be the exception.
> Reflect in the documentation that const_true() is less powerful and
> that statically_true() is the overall preferred solution.
>
> [1] __builtin_constant_p cannot resolve to const when optimizing
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
>
> [2] commit 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()")
> Link: https://git.kernel.org/torvalds/c/3c8ba0d61d04
>
> [3] https://godbolt.org/z/E4r7EaxW9
>
> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
> ---
> include/linux/compiler.h | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 30ce06df4153cfdc0fad9bc7bffab9097f8b0450..165aa5b9bc484376087a130a1ac1f3edb50c983d 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -357,6 +357,29 @@ static inline void *offset_to_ptr(const int *off)
> */
> #define is_const(x) __is_const_zero(0 * (x))
>
> +/*
> + * Similar to statically_true() but produces a constant expression
No.
It tests whether a value is a 'constant integer expression' and
the result is a 'constant integer expression'.
statically_true() checks for the value being a 'compile time constant'.
Most code really doesn't care, it all got added to min() so that
a very few places could do:
char foo[min(16, sizeof (type))];
without triggering the 'variable length array' warning.
But that just bloated everywhere else and (IIRC) Linus replaced
them with a MIN() that was just an expression.
> + *
> + * To be used in conjunction with macros, such as BUILD_BUG_ON_ZERO(),
> + * which require their input to be a constant expression and for which
> + * statically_true() would otherwise fail.
Use a different BUILD_BUG macro instead.
Look at the current definition of min().
David
> + *
> + * This is a trade-off: is_const_true() requires all its operands to
> + * be compile time constants. Else, it would always returns false even
> + * on the most trivial cases like:
> + *
> + * true || non_const_expr
> + *
> + * On the opposite, statically_true() is able to fold more complex
> + * tautologies and will return true on expressions such as:
> + *
> + * !(non_const_expr * 8 % 4)
> + *
> + * For the general case, statically_true() is better.
> + */
> +#define is_const_true(x) __is_const_zero((x) == 0)
> +#define is_const_false(x) __is_const_zero((x) != 0)
> +
> /*
> * This is needed in functions which generate the stack canary, see
> * arch/x86/kernel/smpboot.c::start_secondary() for an example.
>
> --
> 2.45.2
>
>
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2024-12-04 18:49 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 17:33 [PATCH 00/10] compiler.h: refactor __is_constexpr() into is_const{,_true,_false}() Vincent Mailhol via B4 Relay
2024-12-02 17:33 ` [PATCH 01/10] compiler.h: add statically_false() Vincent Mailhol via B4 Relay
2024-12-04 18:30 ` David Laight
2024-12-05 15:25 ` Vincent Mailhol
2024-12-06 3:39 ` David Laight
2024-12-06 4:42 ` Vincent Mailhol
2024-12-02 17:33 ` [PATCH 02/10] compiler.h: add is_const() as a replacement of __is_constexpr() Vincent Mailhol via B4 Relay
2024-12-04 18:39 ` David Laight
2024-12-04 21:20 ` Yury Norov
2024-12-05 15:31 ` Vincent Mailhol
2024-12-06 2:25 ` David Laight
2024-12-06 6:14 ` Linus Torvalds
2024-12-06 7:19 ` Vincent Mailhol
2024-12-06 8:49 ` Vincent Mailhol
2024-12-06 8:29 ` Martin Uecker
2024-12-06 18:30 ` Vincent Mailhol
2024-12-06 18:52 ` Linus Torvalds
2024-12-06 19:02 ` Linus Torvalds
2024-12-06 19:06 ` David Laight
2024-12-06 19:15 ` Linus Torvalds
2024-12-06 19:38 ` Willy Tarreau
2024-12-06 19:43 ` David Laight
2024-12-06 19:38 ` David Laight
2024-12-06 20:23 ` David Laight
2024-12-07 7:42 ` Vincent Mailhol
2024-12-07 11:19 ` David Laight
2024-12-07 12:24 ` Vincent Mailhol
2024-12-07 18:19 ` Linus Torvalds
2024-12-07 19:51 ` Martin Uecker
2024-12-07 20:31 ` Linus Torvalds
2024-12-07 20:54 ` David Laight
2024-12-07 21:00 ` David Laight
2024-12-07 21:06 ` Martin Uecker
2024-12-07 21:45 ` David Laight
2024-12-09 9:59 ` Rasmus Villemoes
2024-12-06 6:40 ` Martin Uecker
2024-12-06 7:26 ` Vincent Mailhol
2024-12-07 8:39 ` Martin Uecker
2024-12-07 10:33 ` David Laight
2024-12-07 13:07 ` Martin Uecker
2024-12-07 18:26 ` Linus Torvalds
2024-12-07 19:19 ` Martin Uecker
2024-12-07 20:28 ` Linus Torvalds
2024-12-07 23:52 ` Martin Uecker
2024-12-08 1:58 ` Linus Torvalds
2024-12-08 9:18 ` Martin Uecker
2024-12-08 11:26 ` David Laight
2024-12-08 12:38 ` Martin Uecker
2024-12-08 16:48 ` David Laight
2024-12-08 18:10 ` Martin Uecker
2024-12-08 19:05 ` Linus Torvalds
2024-12-07 12:45 ` Vincent Mailhol
2024-12-07 13:18 ` Martin Uecker
2024-12-07 13:50 ` Vincent Mailhol
2024-12-07 14:59 ` Martin Uecker
2024-12-07 15:10 ` Martin Uecker
2024-12-07 15:23 ` Vincent Mailhol
2024-12-07 18:07 ` David Laight
2024-12-06 9:34 ` David Laight
2024-12-02 17:33 ` [PATCH 03/10] compiler.h: add is_const_true() and is_const_false() Vincent Mailhol via B4 Relay
2024-12-04 18:48 ` David Laight [this message]
2024-12-05 15:48 ` Vincent Mailhol
2024-12-02 17:33 ` [PATCH 04/10] linux/bits.h: simplify GENMASK_INPUT_CHECK() by using is_const_true() Vincent Mailhol via B4 Relay
2024-12-04 18:52 ` David Laight
2024-12-05 15:49 ` Vincent Mailhol
2024-12-02 17:33 ` [PATCH 05/10] minmax: simplify __clamp_once() by using is_const_false() Vincent Mailhol via B4 Relay
2024-12-04 18:54 ` David Laight
2024-12-05 15:52 ` Vincent Mailhol
2024-12-09 12:32 ` Vincent Mailhol
2024-12-02 17:33 ` [PATCH 06/10] fortify: replace __is_constexpr() by is_const() in strlen() Vincent Mailhol via B4 Relay
2024-12-04 18:58 ` David Laight
2024-12-05 15:53 ` Vincent Mailhol
2024-12-02 17:33 ` [PATCH 07/10] overflow: replace __is_constexpr() by is_const() Vincent Mailhol via B4 Relay
2024-12-02 17:33 ` [PATCH 08/10] drm/i915/reg: replace __is_const_expr() by is_const_true() or is_const() Vincent Mailhol via B4 Relay
2024-12-04 19:00 ` David Laight
2024-12-05 15:56 ` Vincent Mailhol
2024-12-02 17:33 ` [PATCH 09/10] coresight: etm4x: replace __is_const_expr() by is_const() Vincent Mailhol via B4 Relay
2024-12-02 17:33 ` [PATCH 10/10] compiler.h: remove __is_constexpr() Vincent Mailhol via B4 Relay
2024-12-04 23:58 ` [PATCH 00/10] compiler.h: refactor __is_constexpr() into is_const{,_true,_false}() Kees Cook
2024-12-05 15:21 ` Vincent Mailhol
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=c617483816b54096ba4b30bea595da49@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Martin.Uecker@med.uni-goettingen.de \
--cc=airlied@gmail.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavoars@kernel.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=james.clark@linaro.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=llvm@lists.linux.dev \
--cc=luc.vanoostenryck@gmail.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mike.leach@linaro.org \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=rikard.falkeborn@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=suzuki.poulose@arm.com \
--cc=torvalds@linux-foundation.org \
--cc=tursulin@ursulin.net \
--cc=yury.norov@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox