Page MenuHomeFreeBSD

kernel/gcc: turn off -Werror=unused-variable
AbandonedPublic

Authored by bz on Apr 14 2025, 7:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Oct 14, 4:13 AM
Unknown Object (File)
Mon, Sep 29, 12:26 AM
Unknown Object (File)
Wed, Sep 17, 4:58 AM
Unknown Object (File)
Aug 26 2025, 12:17 PM
Unknown Object (File)
Aug 25 2025, 4:31 AM
Unknown Object (File)
Aug 12 2025, 2:02 PM
Unknown Object (File)
Aug 10 2025, 6:01 PM
Unknown Object (File)
Aug 6 2025, 6:13 AM
Subscribers

Details

Reviewers
jhb
imp
lwhsu
Summary

We have header files with static const char *[] which gets included
but the static definitions are not used leading to errors.

/workspace/src/sys/net/if_strings.h:69:20: error: 'ifcap_bit_names' defined but not used [-Werror=unused-variable]

69 | static const char *ifcap_bit_names[] = {

/workspace/src/sys/net/sff8472.h:418:20: error: 'sff_8024_id' defined but not used [-Werror=unused-variable]

418 | static const char *sff_8024_id[SFF_8024_ID_LAST + 1] = {

These are triggered by src/tools/build/test-includes
as at least the 2nd one would otherwise be fine.
For if_strings.h we do have an #include which does not use the variable
(sys/net/if.c).

Sponsored by: The FreeBSD Foundation
Reported by: CI for gcc12/13/14

Test Plan

None. If someone wants to fix this proper be my guest.
I am just tired of the three extra emails from CI per commit/build.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 63511
Build 60395: arc lint + arc unit

Event Timeline

bz requested review of this revision.Apr 14 2025, 7:07 PM
bz created this revision.

Those static definitions are going to multiple files. The warning is legit.

Hmm, I built world + kernel with GCC 14 after fixing a few things last week and this wasn't one of them? iwx(4) had some warnings like this at the time, but @thj fixed those.

In D49830#1138827, @jhb wrote:

Hmm, I built world + kernel with GCC 14 after fixing a few things last week and this wasn't one of them? iwx(4) had some warnings like this at the time, but @thj fixed those.

I got them from CI for all three gcc versions, e.g.:
https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc14_build/287/console

I just pushed the fixes I need for a world + kernel build to complete. I did not hit the error you are getting in test-includes at all. Not at all clear to me why CI is seeing them. I wonder if NO_CLEAN builds don't re-run test-includes on changes?

Also, this build:

https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc14_build/186/

finished fine and it's date (March 31st, so a few weeks ago) is well after the last change to sys/net/if_strings.h for example:

commit 2131654bde1f91b04c959b388cffbf825a433d27
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: Wed Feb 7 03:51:21 2024 +0200
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: Fri Jul 12 06:29:32 2024 +0300

    sys/net: Add IPSEC_OFFLOAD interface cap and methods structure
    
    Reviewed by:    glebius
    Sponsored by:   NVIDIA networking
    Differential revision:  https://reviews.freebsd.org/D44314

Something else is amiss here.

Sigh, so my builds work fine because I had versions of these built from before. Note that we intentionally enabled this specific warning for both Clang and GCC back in 2023 (it used to be disabled). I'm not sure why clang's version is too broken to flag this correctly. Probably this is just poor form in headers, and notably an actual kernel build doesn't fail. The only warning I get from if.c with GCC is:

--- if.o ---
/usr/home/john/work/freebsd/main/sys/net/if.c: In function 'ifioctl':
/usr/home/john/work/freebsd/main/sys/net/if.c:3109:34: warning: 'ifgr32' may be used uninitialized [-Wmaybe-uninitialized]
 3109 |                 ifgr32->ifgr_len = thunk.ifgr.ifgr_len;
      |                 ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
/usr/home/john/work/freebsd/main/sys/net/if.c:2918:30: note: 'ifgr32' was declared here
 2918 |         struct ifgroupreq32 *ifgr32;
      |                              ^~~~~~

BTW, for other arrays like this in <sys/disklabel.h> and <sys/resource.h> we require consumers to define a special macro to expose the array of names (e.g. _RLIMIT_IDENT for the resource limit names). That is probably the correct fix.

See D49954 and D49955 for one approach. I also tested patching tools/build/test-includes/Makefile to add -Wno-unused-variable to CFLAGS for these specific headers.

Thanks for the proper fixes @jhb!