[PATCH 0/4] Fix the x86 defconfig build with GCC 17

[PATCH 0/4] Fix the x86 defconfig build with GCC 17

[Vineet Gupta]

Fix build warnings and failures (CONFIG_WERROR=y) with a GCC 17 build.
GCC 17 adds -Wconstant-logical-operand which is strict about operands
of && or || that fold to a constant other than 0 or 1.

In the past similar fixes have been done for clang, e.g.

  93f56de25937 2017-04-06 mac80211: Fix clang warning about constant operand in logical operation  [v4.12-rc1]
  ...
  dd7fe5d9fd6a 2024-01-17 rtc: max31335: Fix comparison in max31335_volatile_reg()                 [v6.8-rc1]

The reason this trips only with gcc is that clang's toggle is more
permissive:
 - it checks RHS only, not constant LHS.
 - Macros are not checked.

Fix is to effectively make a macro or condition return 0 or 1.

The patches are split up per subsystem and can go independently via
respective trees:

  1/4 x86/cpufeatures: the awk-generated *_MASK_BIT_SET() returns 0 or 1.
  2/4 wait: ___wait_is_interruptible() with a constant state.
  3/4 iommupt: PT_SUPPORTED_FEATURE() in the fvalog2_*() helpers.
  4/4 drm/i915: IS_POWER_OF_2() in reg_bits.h, and two Kconfig timeouts.

Tested on x86 defconfig with CONFIG_WERROR=y, at each patch:

 - GCC 17 trunk (20261103): each patch removes only its own errors. The
   build has no warnings after 4/4.
 - GCC 16.1: the build has no warnings. The .text of each object file
   does not change. The only differences come from the build timestamp
   and the release string.

Vineet Gupta (4):
  x86/cpufeatures: Make {REQUIRED,DISABLED}_MASK_BIT_SET() return 0 or 1
  wait: Make ___wait_is_interruptible() return 0 or 1
  iommupt: Make PT_SUPPORTED_FEATURE() return 0 or 1
  drm/i915: Avoid -Wconstant-logical-operand with GCC 17

 arch/x86/tools/cpufeaturemasks.awk          | 4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
 drivers/gpu/drm/i915/i915_config.c          | 2 +-
 drivers/iommu/generic_pt/pt_defs.h          | 2 +-
 include/drm/intel/reg_bits.h                | 2 +-
 include/linux/wait.h                        | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.53.0-Meta

[PATCH 3/4] iommupt: Make PT_SUPPORTED_FEATURE() return 0 or 1

[Vineet Gupta]

GCC 17 adds -Wconstant-logical-operand to -Wall. It warns when an operand
of && or || folds to a constant other than 0 or 1. PT_SUPPORTED_FEATURE()
returns the raw feature bit, and the fvalog2_*() helpers use it as an &&
operand. The build fails with CONFIG_WERROR=y:

  drivers/iommu/generic_pt/fmt/../pt_defs.h:255:51: error: use of logical '&&' with constant operand '2' [-Werror=constant-logical-operand]

clang has the same warning, but it checks only a constant right operand.

Compare the masked value against 0. All users test the result as a truth
value, so the behaviour does not change.

Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
---
 drivers/iommu/generic_pt/pt_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/generic_pt/pt_defs.h b/drivers/iommu/generic_pt/pt_defs.h
index 707b3b0282fa..51a9c1c5fcc9 100644
--- a/drivers/iommu/generic_pt/pt_defs.h
+++ b/drivers/iommu/generic_pt/pt_defs.h
@@ -200,7 +200,7 @@ static inline bool pt_table_install32(struct pt_state *pts, u32 table_entry)
 	return ret;
 }
 
-#define PT_SUPPORTED_FEATURE(feature_nr) (PT_SUPPORTED_FEATURES & BIT(feature_nr))
+#define PT_SUPPORTED_FEATURE(feature_nr) ((PT_SUPPORTED_FEATURES & BIT(feature_nr)) != 0)
 
 static __always_inline bool pt_feature(const struct pt_common *common,
 			      unsigned int feature_nr)
-- 
2.53.0-Meta

[PATCH 4/4] drm/i915: Avoid -Wconstant-logical-operand with GCC 17

[Vineet Gupta]

GCC 17 adds -Wconstant-logical-operand to -Wall. It warns when an operand
of && or || folds to a constant other than 0 or 1. Three places break the
build with CONFIG_WERROR=y:

  include/drm/intel/reg_bits.h:27:48: error: use of logical '&&' with constant operand '256' [-Werror=constant-logical-operand]
  drivers/gpu/drm/i915/i915_config.c:13:43: error: use of logical '&&' with constant operand '10000' [-Werror=constant-logical-operand]
  drivers/gpu/drm/i915/gem/i915_gem_context.c:999:45: error: use of logical '&&' with constant operand '20000' [-Werror=constant-logical-operand]

clang has the same warning, but it checks only a constant right operand
outside a macro. Here each constant is a left operand, and
IS_POWER_OF_2() is also a macro.

Commit 1a839e016e49 ("drm/i915: remove IS_ACTIVE") moved
CONFIG_DRM_I915_FENCE_TIMEOUT to the left of && to avoid the clang
warning. That does not help with GCC 17.

Compare each constant against 0, as commit aeedd3a82678 ("drm/i915: Avoid
-Wconstant-logical-operand in nsecs_to_jiffies_timeout()") did.

Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
 drivers/gpu/drm/i915/i915_config.c          | 2 +-
 include/drm/intel/reg_bits.h                | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c58ffa5a8fa6..1639639dd290 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -996,7 +996,7 @@ static int intel_context_set_gem(struct intel_context *ce,
 	    intel_engine_has_semaphores(ce->engine))
 		__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
 
-	if (CONFIG_DRM_I915_REQUEST_TIMEOUT &&
+	if (CONFIG_DRM_I915_REQUEST_TIMEOUT != 0 &&
 	    ctx->i915->params.request_timeout_ms) {
 		unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
 
diff --git a/drivers/gpu/drm/i915/i915_config.c b/drivers/gpu/drm/i915/i915_config.c
index 9e13b1be407c..9bbebe0a6a70 100644
--- a/drivers/gpu/drm/i915/i915_config.c
+++ b/drivers/gpu/drm/i915/i915_config.c
@@ -10,7 +10,7 @@
 
 unsigned long i915_fence_context_timeout(u64 context)
 {
-	if (CONFIG_DRM_I915_FENCE_TIMEOUT && context)
+	if (CONFIG_DRM_I915_FENCE_TIMEOUT != 0 && context)
 		return msecs_to_jiffies_timeout(CONFIG_DRM_I915_FENCE_TIMEOUT);
 
 	return 0;
diff --git a/include/drm/intel/reg_bits.h b/include/drm/intel/reg_bits.h
index 2a9066e1d808..f913c3e61f39 100644
--- a/include/drm/intel/reg_bits.h
+++ b/include/drm/intel/reg_bits.h
@@ -24,7 +24,7 @@
 /*
  * Local integer constant expression version of is_power_of_2().
  */
-#define IS_POWER_OF_2(__x)		((__x) && (((__x) & ((__x) - 1)) == 0))
+#define IS_POWER_OF_2(__x)		((__x) != 0 && (((__x) & ((__x) - 1)) == 0))
 
 /**
  * REG_FIELD_PREP8() - Prepare a u8 bitfield value
-- 
2.53.0-Meta

Re: [PATCH 0/4] Fix the x86 defconfig build with GCC 17

[Borislav Petkov]

On Wed, Nov 04, 2026 at 08:07:17AM -0800, Vineet Gupta wrote:
> Fix build warnings and failures (CONFIG_WERROR=y) with a GCC 17 build.
> GCC 17 adds -Wconstant-logical-operand which is strict about operands
> of && or || that fold to a constant other than 0 or 1.

Just from looking at it, my initial reaction would be to disable that option.

Because, frankly, I don't see the point.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 0/4] Fix the x86 defconfig build with GCC 17

[Vineet Gupta]

+CC Jakub

On 11/4/26 8:27 AM, Borislav Petkov wrote:
> On Wed, Nov 04, 2026 at 08:07:17AM -0800, Vineet Gupta wrote:
>> Fix build warnings and failures (CONFIG_WERROR=y) with a GCC 17 build.
>> GCC 17 adds -Wconstant-logical-operand which is strict about operands
>> of && or || that fold to a constant other than 0 or 1.
> Just from looking at it, my initial reaction would be to disable that option.
>
> Because, frankly, I don't see the point.

Here's my 2 cents:

I wondered if this brings any codegen improvements, since we are telling 
the compiler that something is 0 or 1 vs. some other range before. And 
it doesn't, because of the way it is used. So focusing on just 1/4.

- Constant bit: __builtin_constant_p(bit) && MASK_BIT_SET(bit) folds at 
compile time to the same truth value, with or without the !! bool 
conversion.
- Variable bit: __builtin_constant_p(bit) is 0, so && short-circuits and 
the mask is never evaluated.

Basically, the masked value never reaches generated code, so compiler 
gets nothing new to work with.

So I did some digging, and turns out that it can be helpful to catch 
bugs in the source code itself. In fact GCC implemented the toggle at 
all, when Jakub spotted an issue with a typo: (data->flags && 
ff_genericize) vs. (data->flags & ff_genericize).

In kernel, the predicate like *_BIT_SET() not returning a bool is not 
clean IMO and it used to return 0/1 before anyway so its not like we are 
going out of the way here.

I'm mildly in the favor of keeping the warning, but ultimately your 
call, I can respin with it disabled.

Thx,
-Vineet

Re: [PATCH 0/4] Fix the x86 defconfig build with GCC 17

[Borislav Petkov]

On November 4, 2026 6:05:27 PM UTC, Vineet Gupta <vineet.gupta@linux.dev> wrote:
>+CC Jakub
>
>On 11/4/26 8:27 AM, Borislav Petkov wrote:
>> On Wed, Nov 04, 2026 at 08:07:17AM -0800, Vineet Gupta wrote:
>>> Fix build warnings and failures (CONFIG_WERROR=y) with a GCC 17 build.
>>> GCC 17 adds -Wconstant-logical-operand which is strict about operands
>>> of && or || that fold to a constant other than 0 or 1.
>> Just from looking at it, my initial reaction would be to disable that option.
>> 
>> Because, frankly, I don't see the point.
>
>Here's my 2 cents:
>
>I wondered if this brings any codegen improvements, since we are telling the compiler that something is 0 or 1 vs. some other range before. And it doesn't, because of the way it is used. So focusing on just 1/4.
>
>- Constant bit: __builtin_constant_p(bit) && MASK_BIT_SET(bit) folds at compile time to the same truth value, with or without the !! bool conversion.
>- Variable bit: __builtin_constant_p(bit) is 0, so && short-circuits and the mask is never evaluated.
>
>Basically, the masked value never reaches generated code, so compiler gets nothing new to work with.
>
>So I did some digging, and turns out that it can be helpful to catch bugs in the source code itself. In fact GCC implemented the toggle at all, when Jakub spotted an issue with a typo: (data->flags && ff_genericize) vs. (data->flags & ff_genericize).
>
>In kernel, the predicate like *_BIT_SET() not returning a bool is not clean IMO and it used to return 0/1 before anyway so its not like we are going out of the way here.
>
>I'm mildly in the favor of keeping the warning, but ultimately your call, I can respin with it disabled.
>
>Thx,
>-Vineet

You might wanna look at the W= switches we have for less popular and more noisy options
-- 
Small device. Typos and formatting crap

Re: [PATCH 0/4] Fix the x86 defconfig build with GCC 17

[Peter Zijlstra]

On Wed, Nov 04, 2026 at 08:27:47AM -0800, Borislav Petkov wrote:
> On Wed, Nov 04, 2026 at 08:07:17AM -0800, Vineet Gupta wrote:
> > Fix build warnings and failures (CONFIG_WERROR=y) with a GCC 17 build.
> > GCC 17 adds -Wconstant-logical-operand which is strict about operands
> > of && or || that fold to a constant other than 0 or 1.
> 
> Just from looking at it, my initial reaction would be to disable that option.
> 
> Because, frankly, I don't see the point.

Yes, this. This seems like a really pointless warning to me too.