From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.252 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793815540; b=ymG6B5huhROjydIbfhAAcTWVFxQEuuVi2WWiZCJD+Q1O8PJdILuF7DVHf6WAykJ5vUQm /IMLaXNyaGBQFUo+4SqmZ4nclIcCXsFLVZMomJGKNMvNmJTBZpiMut68QSGz3uYXD/lac Zoh32LstNxYiShTSSuO0GZnqRAx8e4DStnOgcRWt28RzNP2syTjqmrRTTHB9/12dGI0Gi NRvH07yn2thZYIA27mz4x4t8itv6MlBv7ATddNWcntuAvNDS7RPk+B5nE9yOxrBZVWy33 5UtWBAAh/+LB4h6QMX/ExQuwmUbalNowlenETJZjTcZFvcaiQg3Yns/xFNavg9xJRbw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793815540; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:From:Content-Language:In-Reply-To: Content-Type:Content-Transfer-Encoding; bh=8t2Xff/1DSUKaDzEnQpPidhAwqFbrWLlVj0t+jNDN2Q=; b=RW84ewFewr836JWlNEx2TuCrhT/0zL0PYplMFRuWRnB7BC7wYPRZrVLvZFA80DfsEJEU mKoI9kzYeZasd/C/m7hQE4YZ1gI3oiViwhIP0rVLWwz0BaEFibmcL+Q6rj+S/ld+//PT+ 8iVn71ssNVbHm9qY3dGPlstizg162FC/rRqCC5z4BtEZ7nG0n2dsism8r7qVe1SIj0Ueu e29hpYyDc0ctRZ2u9NrQbVSdjWHsGggWIDFappGMdx7qu+nzruBYHOZnQENLeUG1LzyPc ESJNdO/ilNDcx8OnPda7yEb7xSlfsZTIqU+Uv4KgG9fqoLhaXWm3vW8InUKJNe67qSQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=nGaW00kZ; arc=none smtp.remote-ip=95.215.58.252 Received: from mta1.migadu.com (out-252.mta1.migadu.com [95.215.58.252]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A964606A328 for ; Wed, 4 Nov 2026 18:05:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 8A964606A328 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=nGaW00kZ X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=APEjYZTpAPwsLJnzLt2e35nbL7x74iTU9z6VBsbq6/4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793815537; v=1; x=1794420337; b=nGaW00kZ1kYe0iUwf1lyS2kx6eH+kH2DTylQy9zXAjKjIvKqZ3WUS6SVRm+WxIw5vd7N8CcV nDzxC3mHGakCh/xPgduGr/mbSPCDT6hdDzRpi12SUMgnAEKX6ClnUjJ4LJu19YbAOSnC9ZZjPLn 8z6WPn0XNaKs0WF7ieOAPqnQ= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 6cce56c66b11413f; Wed, 04 Nov 2026 18:05:36 +0000 X-Mizu-Trace-ID: 6cce56c66b11413f X-Migadu-Flow: FLOW_OUT Message-ID: <327c462a-3360-45fa-8398-4c23c1f2bd84@linux.dev> Date: Wed, 4 Nov 2026 10:05:27 -0800 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] Fix the x86 defconfig build with GCC 17 To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Peter Zijlstra , Juri Lelli , Vincent Guittot , "Joerg Roedel (AMD)" , Will Deacon , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Matthew Brost , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , "H. Peter Anvin" , "Xin Li (Intel)" , Brian Gerst , Nikolay Borisov , linux-kernel@vger.kernel.org, Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Robin Murphy , iommu@lists.linux.dev, Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, llvm@lists.linux.dev, Jakub Jelinek References: <20261104160722.1637541-1-vineet.gupta@linux.dev> <20261104162747.GAautdA2q2lw2gsth2@fat_crate.local> From: Vineet Gupta Content-Language: en-US In-Reply-To: <20261104162747.GAautdA2q2lw2gsth2@fat_crate.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit +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