Re: [PATCH] scripts/sorttable: Mark long_size as __maybe_unused

[Nathan Chancellor <nathan@kernel.org>]

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@vger.kernel.org
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > 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@gmail.com/
> > 
> > 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@fritz.com>

Thanks. Given how trivial this is and since it needs to go to stable,
could you take this via kbuild-fixes?

-- 
Cheers,
Nathan