From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D7533B3C05 for ; Fri, 10 Apr 2026 09:10:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775812203; cv=none; b=S7SHxA1mNywdyL86X20yFl94zfYDsdRKGIITxtV7UebrtiBYqab9R6DedunN25/8hu3Tk0IfjbeUknMKag2YCC8OOlWlgnOswo12av4YHV0kZcyKT6S1Y3iQ3+rf79yhrSEe+8cfMaF5cIkg7cUyhbQX1ypelrzyGWuh4TFeTwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775812203; c=relaxed/simple; bh=7R60hFvlb/5KoGz2efYGOHyPwu/YCKtYubFE0c4cCcc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nFfJ+/L96wFre802ejQ00u5kxCP11WKvOEOdK/rdTgVtuU/KapRTSf0DhNfhTBkQ/eyMesvrMXKaKOIyT1BE7C5nPOff/9k7e2AtuyinyzgJaxGJ2pRoHv71LffK8AC58b8yU+hXL33pCG21uG2bCTLggw4N6BWz2DT3RJNUe5Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iVF44b0c; arc=none smtp.client-ip=209.85.221.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iVF44b0c" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-43b95e5b3afso1117806f8f.3 for ; Fri, 10 Apr 2026 02:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775812199; x=1776416999; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=h6UTecoVIwQX1N31qtlZ3rJW2nokYcaQGwmt5vT679I=; b=iVF44b0cPTteduAQiliLCNA01/YkDnAe8DB812X+edVgdHCk4VpD5OLX9Vi2pML6lW iyfmjF8o/mmRKQkLyzjwFgJmn0B7mpZnVcFfZNNJqc83yT5VA1+tugbw+D+La2CKa5gf Gx9N69ZmuqUpZhWjeQFWs94G9GKoolJlYegfRx8aKRm1OStuvp3xrq6gzQlBDGkazeZO htY0jBs71i8cg8FaLqNhv2qHCrbGmGrT+TfqgfQrD94qKy5a5OiqhJeNjR0biLdTHtj3 gLwWHJr06BoSm9Han10l5gXX3mUo/JBUc81IBcP35dXYyABpEi6E9x0p25coS/FM/ih8 aIlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775812199; x=1776416999; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=h6UTecoVIwQX1N31qtlZ3rJW2nokYcaQGwmt5vT679I=; b=N+rbPghLPokpK8lX5zy0Hnwsu2EPr020/qFCQlt09VWVCOZtDuyM0GEzI0jplcDRuO rYoSc98iJb8xUMP3+MHVB/bam7QdmRqdZwhYGTt7l4vvGgZMrTP67pBaRQinmwAT2Kq+ Ux8lSFOYh9bX7z2JPYdII3t3rGTCAry9ls5nLFhflrzApALK4LY/vl4qpne/+TPDUudb Y8W9HtDrmh9l3vVFAl9VKeg4O0vk2RM1KX1uSnJ7+xNEwdWDtHXJdHNEpXzS9Q3VhMMp TVzWRDj+pL/wNnHsjVbpnAlgGdgSYnY7XGpyzQgRYyct8rS8fsB01OkpmEjFPcaddgfe /vVw== X-Forwarded-Encrypted: i=1; AJvYcCVgQCm9hY+J1bUP50XjqOvzx65TrBhgrdAgZCjWoJHgXnJFtcDVxeuAV43DfUk4BqoxdB2Lj53Nms+CWbY=@vger.kernel.org X-Gm-Message-State: AOJu0YzJIgshHatBQfVswQJch0WB9VXz+hehbjsvuRMol7562r39nNLT A1sb/9mWXt26n00FoxvwI1ybHWmxnZ2Vw26sSWbDntA8pNgTY6buY/0+ X-Gm-Gg: AeBDieu+R836/Sr6tajmkO9ajEdtkeLxUsKrIKvIVOHmJzzMSDlPSCTTP7hm/ANrGvi IGlOeVWC8nb0nVXaeX+WTauVKCcErQphAzYiqhaunCw9xXuwhCzPufuvj+aOEjUkFZDVyiiM+Kl wfn4Tj0TdJHf6SvDWV9sjYF/PI1npn4MegKfEqkZ0DcSyn11+bCwhH6d5lgaVOS7VX3SszWmI4c 5pYDE3Zf1vCcp3dDCcv5qn6UNf4K4FnOlP5Tr60EU///+FRA35vAHU9r/42NgSG8i41m70lTXoK 6LIeBZQQk9DOLW3dn5GFgI+mBBSOZf3MUUbxp8+BYi92XUZr2SFyg97Rzg3NCihhOYGN+bE6hkT kmZMZcxLpLKQ9y5bQZ2uIpd7EmW8rzC0IFWQriqgjAZ7v1c7vjNh1Mw9hJEQ0+kGtYpsql96cRJ A1XQbbW9MB8Sqq5ETaSGKMDkmPsZdenvxmTyCzpESckJR1wHikCygdMYFGOYXgWst8KbywLB1qJ pI= X-Received: by 2002:a05:6000:18a8:b0:43d:a58:b076 with SMTP id ffacd0b85a97d-43d642cbb36mr3626186f8f.44.1775812199358; Fri, 10 Apr 2026 02:09:59 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d63de343bsm5780304f8f.8.2026.04.10.02.09.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2026 02:09:58 -0700 (PDT) Date: Fri, 10 Apr 2026 10:09:57 +0100 From: David Laight To: Yury Norov Cc: Matt Coster , Yury Norov , Rasmus Villemoes , Frank Binns , Alessio Belle , Brajesh Gupta , Alexandru Dadu , linux-kernel@vger.kernel.org, Vincent Mailhol , kernel test robot Subject: Re: [PATCH] bitfield: Fix FIELD_PREP_CONST() with __GENMASK_ULL() on gcc<14 Message-ID: <20260410100957.7f9bba98@pumpkin> In-Reply-To: References: <20260409-field-prep-fix-v1-1-f0e9ae64f63c@imgtec.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 9 Apr 2026 13:46:20 -0400 Yury Norov wrote: > On Thu, Apr 09, 2026 at 03:57:53PM +0100, Matt Coster wrote: > > There is a bug in gcc<14[1] that causes the following minimal example to > > not be treated as a constant: > > > > int main() { > > sizeof(struct { > > int t : !(__builtin_ffsll(~0ULL) + 1 < 0); > > }); > > } > > > > test.c: In function 'main': > > test.c:3:21: error: bit-field 't' width not an integer constant > > 3 | int t : !(__builtin_ffsll(~0ULL) + 1 < 0); > > | ^ > > > > Hi Matt, > > Thanks for digging this! > > So for me even > > int t : __builtin_ffsll(~1ul); > > doesn't work. But '~1' or '1ull' works well. My GCC is 13.3.0. > Clearly a compiler bug. I one line comment that expressions involving __builtin_ffsll(1ull << 63) aren't always constant is probably enough. Change the test from !(...) to (...)?1:2 to avoid the zero-sized bitfield error. (and s/main/fubar/;s/sizeof/return sizeof/ to avoid other errors.) It is all very strange (I suspect there is a uninitialised value somewhere). Change the '+ 1' to '+ 0' and it is ok, but '+ 0u' fails. If it is uninitialised stack then some of the changes really are random. So even the 'long long' cast may not guarantee to avoid the problem. I've just 'lobbed in' a different patch. David > > > The result of this bug is a bizarre interaction between FIELD_PREP_CONST() > > and __GENMASK_ULL(). Note that this does not occur with GENMASK_ULL() since > > that has not been based on the UAPI variant since commit 104ea1c84b91 > > ("bits: unify the non-asm GENMASK*()"). > > > > The underlying compiler bug has been fixed in gcc since 14.1.0, but the fix > > appears to have been incidental in a larger change[2]. > > > > [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124699 > > [2]: https://gcc.gnu.org/cgit/gcc/commit/?id=0d00385eaf72ccacff17935b0d214a26773e095f > > > > Reported-by: kernel test robot > > Closes: https://lore.kernel.org/oe-kbuild-all/202603222211.A2XiR1YU-lkp@intel.com/ > > Signed-off-by: Matt Coster > > --- > > Some below-the-dash thoughts: > > > > This is the most minimal workaround I could find. I'm not sure what a > > "real" fix would look like here so I'm open to suggestions. > > > > The reproduction case is amazing because changing almost any subtle > > detail of it will result in the expression correctly being parsed as > > constant (even raising the construct to file scope; the use of > > BUILD_BUG_ON_ZERO() is part of the bizarre confluence required to > > trigger the bug). > > > > The complexity of the associated change in gcc makes it difficult to > > trace what actually changed to fix the underlying bug. If I had more > > time, I'd have dug in further and (tried to) come up with an answer. > > > > In reality, the (long long) cast could probably just be univerally > > applied without the conditional compilation. My only concern with that > > approach is that it risks turning the workaround into an arcane > > incantation whose meaning will eventually have been lost to time. > > --- > > include/linux/bitfield.h | 30 +++++++++++++++++++++++++++--- > > 1 file changed, 27 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h > > index 54aeeef1f0ec7..12f5c5a3c8d72 100644 > > --- a/include/linux/bitfield.h > > +++ b/include/linux/bitfield.h > > @@ -46,6 +46,30 @@ > > > > #define __bf_shf(x) (__builtin_ffsll(x) - 1) > > > > +#if defined(GCC_VERSION) && (GCC_VERSION < 140000) > > +/* > > + * This workaround is required for gcc<14. The issue is an interaction between > > + * FIELD_PREP_CONST() and __GENMASK_ULL() that can be boiled down this MCVE, > > + * which fails to compile as GCC doesn't recognize the expression as constant: > > + * > > + * int main() { > > + * sizeof(struct { > > + * int t : !(__builtin_ffsll(~0ULL) + 1 < 0); > > + * }); > > + * } > > + * > > + * The underlying issue was inadvertently "fixed" (or perhaps sidestepped) in > > + * commit 0d00385eaf7 ("wide-int: Allow up to 16320 bits wide_int and change > > + * widest_int precision to 32640 bits [PR102989]"), which first appeared in > > + * GCC 14.1. > > So GCC_VERSION should be < 140100 I guess? > > > + * > > + * See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124699 > > + */ > > +#define __const_bf_shf(x) __bf_shf((long long)(x)) > > +#else > > +#define __const_bf_shf(x) __bf_shf(x) > > +#endif > > The 'const' part looks misleading. There's really nothing const in > there. Can you just fix the __bf_shf() instead? > > > #define __scalar_type_to_unsigned_cases(type) \ > > unsigned type: (unsigned type)0, \ > > signed type: (unsigned type)0 > > @@ -157,11 +181,11 @@ > > /* mask must be non-zero */ \ > > BUILD_BUG_ON_ZERO((_mask) == 0) + \ > > /* check if value fits */ \ > > - BUILD_BUG_ON_ZERO(~((_mask) >> __bf_shf(_mask)) & (_val)) + \ > > + BUILD_BUG_ON_ZERO(~((_mask) >> __const_bf_shf(_mask)) & (_val)) + \ > > /* check if mask is contiguous */ \ > > - __BF_CHECK_POW2((_mask) + (1ULL << __bf_shf(_mask))) + \ > > + __BF_CHECK_POW2((_mask) + (1ULL << __const_bf_shf(_mask))) + \ > > /* and create the value */ \ > > - (((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask)) \ > > + (((typeof(_mask))(_val) << __const_bf_shf(_mask)) & (_mask)) \ > > ) > > Now you fix FIELD_PREP_CONST() only, but there might be other > potential victims, so fixing __bf_shf() would help them all. > > Thanks, > Yury > > > /** > > > > --- > > base-commit: b20a9b5f9c4baeae0b2e143046b195b910c59714 > > change-id: 20260324-field-prep-fix-fdfc4eb68156 >