Re: [PATCH] scripts/sorttable: Mark long_size as __maybe_unused
From: Nathan Chancellor
Date: Tue Sep 08 2026 - 19:37:15 EST
On Fri, Sep 04, 2026 at 09:34:10PM +0200, Nicolas Schier wrote:
> On Mon, Aug 31, 2026 at 06:46:31PM -0700, Nathan Chancellor wrote:
> > When building in a kernel tree prior to commit b055f4c431e3 ("sorttable:
> > Move ELF parsing into scripts/elf-parse.[ch]") with clang-23 or newer,
> > which implements a new warning under -Wunused-but-set-variable for
> > static global variable, there is a warning from sorttable because
> > long_size is unused when MCOUNT_SORT_ENABLED is not set:
> >
> > scripts/sorttable.c:452:12: error: variable 'long_size' set but not used [-Werror,-Wunused-but-set-global]
> > 452 | static int long_size;
> > | ^
> >
> > Mark long_size as __maybe_unused to avoid inserting more ugly #ifdef
> > directives while insuring the warning does not reappear, as the
> > aforementioned change does not alter the uses of long_size, so it
> > appears to be coincidence that the warning disappears after this
> > refactoring.
> >
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> > ---
> > This is breaking our builds on stable:
> >
> > https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/33143924291
> >
> > There was a previous patch sent for this issue
> >
> > https://lore.kernel.org/20260603191708.27241-1-beakthoven@xxxxxxxxx/
> >
> > but it was marked as stable only. I think this should be taken via
> > mainline and backported the normal way, as it appears to be coincidence
> > that the warning is not present in mainline. It does not look like
> > scripts/sorttable.c has a formal owner according to MAINTAINERS so this
> > could either go through one of Steve's trees or the kbuild tree.
> > ---
> > scripts/sorttable.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Thanks!
>
> Tested-by: Nicolas Schier <n.schier@xxxxxxxxx>
Thanks. Given how trivial this is and since it needs to go to stable,
could you take this via kbuild-fixes?
--
Cheers,
Nathan