toolchain: gcc: add initial support for GCC 16.1

[DragonBluep]

• It seems that -mips16 option doesn't take effect on MIPS platforms, need help.

[openwrt-ai]

Commit checks

• d7a2738 "CI: DROP ME!!!!!!!!!!!!!!!!!!!!!!!!!!!!" — author-flagged placeholder; the commit body says "Please remove this commit before merging." Drop it (and rebase) before this PR is mergeable.

---

To address review feedback, force-push fixes to this branch. Don't close and open a new PR — that loses the review history and the bot starts from scratch.

---

Generated by Claude Code

[openwrt-ai]

When GCC_USE_VERSION_14 is selected, GCC_VERSION now resolves to "16.1.0" instead of "14.3.0": there's no config GCC_VERSION_14 symbol and no explicit default "14.3.0" if GCC_VERSION_14, so a GCC 14 selection falls past every conditional and lands on the unconditional "16.1.0" default that replaced the old "14.3.0" fallback. The gcc 14.x choice in Config.in is still selectable, so this silently mis-versions GCC 14 builds.

Separately, default "16.1.0" if GCC_VERSION_16 immediately followed by an unconditional default "16.1.0" is redundant — the unconditional line already covers the same case.

Related, default y if !TOOLCHAINOPTS || GCC_USE_VERSION_14 at Config.version:28 is not updated by this PR: GCC_USE_DEFAULT_VERSION (which implys KERNEL_WERROR) is still keyed off GCC 14, so building with the new default GCC 16 no longer implies KERNEL_WERROR. It should reference GCC_USE_VERSION_16.

A self-consistent fix is to add a config GCC_VERSION_14 block and an explicit default "14.3.0" if GCC_VERSION_14, drop the redundant default "16.1.0" if GCC_VERSION_16 (keeping only the unconditional fallback as the marker of the current default version, matching the prior style), and update GCC_USE_DEFAULT_VERSION to key off GCC_USE_VERSION_16.

---

Generated by Claude Code

[rockdrilla]

I would take a look in next days or so (I've finally got GCC 16.1 as host compiler).

[openwrt-ai]

Re-reviewed against 684e5ca after the force-push. The "CI: DROP ME" commit flagged previously was rebased away and replaced with 684e5ca ("refresh GCC 16.1 patches"); thanks for cleaning that up.

I want to retract my prior comment on toolchain/gcc/Config.version — I misread the kconfig flow. With GCC_USE_VERSION_14 selected, none of the if GCC_VERSION_* defaults match, so GCC_VERSION correctly falls through to the unconditional "14.3.0". That is the project's existing convention for "the current default has no explicit GCC_VERSION_N symbol" (see the same shape at Config.version pre-PR), and keeping GCC_USE_DEFAULT_VERSION keyed off GCC_USE_VERSION_14 is consistent with Config.in still defaulting the choice to GCC 14. Sorry for the noise.

The patch refresh in 684e5ca looks like a mechanical line-number update to match GCC 16.1's upstream context, and the two removals (004-libcody-*, 980-fix-build-error-with-Xcode-16.3) are plausibly upstreamed per the SHAs cited in the commit body. PR is still marked draft with the author's -mips16 question outstanding, so no further blocking comments from me.

---

To address review feedback, force-push fixes to this branch. Don't close and open a new PR — that loses the review history and the bot starts from scratch.

---

Generated by Claude Code

[Jebaitedneko]

Hey @DragonBluep, i was able to boot with this change set, thank you very much!

Packages ppp and elfutils needed patches for satisfying LTO
Other than that, everything went well 🎉

Patch for ppp: Jebaitedneko@fa19b91
I'm not sure if this is the right approach, but ppp is functioning well with this change

Patch for elfutils: Jebaitedneko@bcd61e5 (taken from upstream)

Build system: x86/64
Target: mediatek/filogic
Device: dlink_aquila-pro-ai-m30-a1
Kernel Log
Build Config
Build Config (diff)

I'll be daily-driving it from today 😄

[graysky2]

Here is a hacky workaround:

--- a/scripts/patch-specs.sh
+++ b/scripts/patch-specs.sh
@@ -27,15 +27,18 @@ fi
 
 patch_specs() {
 	local found=0
+	local has_libatomic=0
+	find "$DIR" -name "libatomic.so*" -o -name "libatomic.a" 2>/dev/null | grep -q . && has_libatomic=1
 
 	for lib in $(STAGING_DIR="$DIR" "$CPP" -x c -v /dev/null 2>&1 | sed -ne 's#:# #g; s#^LIBRARY_PATH=##p'); do
 		if [ -d "$lib" ]; then
 			grep -qs "STAGING_DIR" "$lib/specs" && rm -f "$lib/specs"
 			if [ $found -lt 1 ]; then
 				echo -n "Patching specs ... "
-				STAGING_DIR="$DIR" "$CPP" -dumpspecs | awk '
+				STAGING_DIR="$DIR" "$CPP" -dumpspecs | awk -v has_libatomic="$has_libatomic" '
 					mode ~ "link" {
 						sub(/(%@?\{L.\})/, "& -L %:getenv(STAGING_DIR /usr/lib) -rpath-link %:getenv(STAGING_DIR /usr/lib)")
+						if (!has_libatomic) gsub(/-latomic_asneeded/, "")
 					}
 					mode ~ "cpp" {
 						$0 = $0 " -idirafter %:getenv(STAGING_DIR /usr/include)"

[rockdrilla]

@graysky2 I'll bump glibc to recent HEAD in next couple of days. This may or may not help of course.

[graysky2]

@rockdrilla - this is a good idea as our glibc is pretty old: #23467 but still hitting the error

[graysky2]

I'm attempting to build x86/64-glibc but I'm running into some problems.

@DragonBluep - I think I solved the build error. Created DragonBluep#2

[graysky2]

@Jebaitedneko -

Patch for elfutils: Jebaitedneko@bcd61e5 (taken from upstream)

#23468 makes that patch unnecessary.

[graysky2]

After applying this PR and the following PRs, I was able to build and boot into a functional image as far as I can tell, great job with this @DragonBluep!

Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc

% dmesg|grep -i gcc
[    0.000000] Linux version 6.18.32 (squish@redline) (x86_64-openwrt-linux-gnu-gcc (OpenWrt GCC 16.1.0 r34553+41-74da669505b0) 16.1.0, GNU ld (GNU Binutils) 2.46.0.20260210) #0 SMP Fri May 22 16:17:08 2026

DragonBluep#2
#23467
#23468
#23469
#23470
openwrt/packages#29518