Build fails on flcn_ls10.c: GCC 16.1.1 ICE in sched2 RTL pass (open 610.43.02, Linux 7.0.12)

[axiom0x0]

NVIDIA Open GPU Kernel Modules Version

610.43.02 (Arch package nvidia-open-dkms 610.43.02-2)

Operating System and Version

Garuda Linux Broadwing

Kernel Release

7.0.12-zen1-1-zen (linux-zen 7.0.12.zen1-1)

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Build Command

make -j32 IGNORE_PREEMPT_RT_PRESENCE=1 NV_EXCLUDE_BUILD_MODULES='' KERNEL_UNAME=7.0.12-zen1-1-zen modules

Terminal output/Build Log

Excerpt from /var/lib/dkms//build/make.log; the file was overwritten by a subsequent successful build with the workaround applied, so this is what I have.

[ nvidia ]  CC  ../common/nvswitch/kernel/ls10/flcn_ls10.c
 during RTL pass: sched2
 ../common/nvswitch/kernel/ls10/flcn_ls10.c: In function ‘_flcnDmemTransfer_LS10’:
 ../common/nvswitch/kernel/ls10/flcn_ls10.c:271:1: internal compiler error: Segmentation fault
   271 | }
       | ^
 0x2593998 diagnostics::context::diagnostic_impl(rich_location*, diagnostics::metadata const*, diagnostics::option_id, char const*, __va_list_tag (*) [1], diagnostics::kind)
        ???:0
 0x2595fa7 internal_error(char const*, ...)
        ???:0
 /usr/lib/gcc/x86_64-pc-linux-gnu/16.1.1/cc1 -quiet -I kernel/inc -I interface -I ../common/sdk/nvidia/inc -I ../common/sdk/nvidia/inc/hw -I arch/nvalloc/common/inc -I arch/nvalloc/common/inc/gsp -I arch/nvalloc/common/inc/deprecated -I arch/nvalloc/unix/include -I inc -I inc/os -I ../common/shared/inc -I ../common/inc -I ../common/uproc/os/libos-v2.0.0/include -I ../common/uproc/os/common/include -I ../common/inc/swref -I ../common/inc/swref/published -I generated -I ../common/nvswitch/kernel/inc -I ../common/nvswitch/interface -I ../common/nvswitch/common/inc/ -I ../common/inc/displayport -I ../common/nvlink/interface/ -I ../common/nvlink/inband/interface -I src/mm/uvm/interface -I inc/libraries -I src/libraries -I inc/kernel -I ../common/mbedtls/3.6.2/include -I ../common/mbedtls/3.6.2/nvidia -MMD _out/Linux_x86_64/flcn_ls10.d -MF _out/Linux_x86_64/flcn_ls10.d.to_be_processed -MP -MT _out/Linux_x86_64/flcn_ls10.o -D NV_LINUX -D NV_X86_64 -D NV_ARCH_BITS=64 -D MBEDTLS_USER_CONFIG_FILE=<nvrm_mbedtls_config.h> -D _LANGUAGE_C -D __NO_CTYPE -D NVRM -D LOCK_VAL_ENABLED=0 -D PORT_ATOMIC_64_BIT_SUPPORTED=1 -D PORT_IS_KERNEL_BUILD=1 -D PORT_IS_CHECKED_BUILD=0 -D PORT_MODULE_atomic=1 -D PORT_MODULE_core=1 -D PORT_MODULE_cpu=1 -D PORT_MODULE_crypto=1 -D PORT_MODULE_debug=1 -D PORT_MODULE_memory=1 -D PORT_MODULE_safe=1 -D PORT_MODULE_string=1 -D PORT_MODULE_sync=1 -D PORT_MODULE_thread=1 -D PORT_MODULE_time=1 -D PORT_MODULE_util=1 -D PORT_MODULE_example=0 -D PORT_MODULE_mmio=0 -D RS_STANDALONE=0 -D RS_STANDALONE_TEST=0 -D RS_COMPATABILITY_MODE=1 -D RS_PROVIDES_API_STATE=0 -D NV_CONTAINERS_NO_TEMPLATES -D INCLUDE_NVLINK_LIB -D INCLUDE_NVSWITCH_LIB -D NV_PRINTF_STRINGS_ALLOWED=1 -D NV_ASSERT_FAILED_USES_STRINGS=1 -D PORT_ASSERT_FAILED_USES_STRINGS=1 -include ../common/sdk/nvidia/inc/cpuopsys.h ../common/nvswitch/kernel/ls10/flcn_ls10.c -quiet -dumpdir _out/Linux_x86_64/ -dumpbase flcn_ls10.c -dumpbase-ext .c -msoft-float -mno-red-zone -mcmodel=kernel -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -mindirect-branch-register -mindirect-branch=thunk-extern -mtune=generic -march=x86-64 -O2 -Wall -Wformat=2 -Wno-unused-parameter -Werror=implicit-function-declaration -Wwrite-strings -Wundef -Wstrict-prototypes -Wold-style-definition -Wno-format-zero-length -std=gnu11 -fno-strict-aliasing -fno-omit-frame-pointer -fno-common -ffreestanding -fno-stack-protector -fno-pic -ffunction-sections -fdata-sections -fcf-protection=branch -fno-jump-tables -o /tmp/ccE3Dzsu.s
 Please submit a full bug report, with preprocessed source (by using -freport-bug).
 Please include the complete backtrace with any bug report.
 See <https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues> for instructions.
 make[1]: *** [Makefile:203: _out/Linux_x86_64/flcn_ls10.o] Error 1
 make[1]: *** Waiting for unfinished jobs....
 make: *** [Makefile:34: src/nvidia/_out/Linux_x86_64/nv-kernel.o] Error 2

More Info

Expected: dkms install produces signed nvidia, nvidia-modeset, nvidia-drm, nvidia-uvm, and nvidia-peermem modules under /usr/lib/modules/<kver>/updates/dkms/.

Actual: Build aborts on flcn_ls10.c with a GCC internal compiler error (segfault) in the sched2 RTL pass while compiling _flcnDmemTransfer_LS10. No modules are installed, the previous kernel's modules are wiped by DKMS first, and the system boots without any NVIDIA driver on the next reboot (in my case: second monitor dark, nvidia_drm/nvidia_uvm missing per journalctl, fallback to modesetting).

Workaround (verified working): appending the following two lines to src/nvidia/Makefile just after the existing CFLAGS += -fno-stack-protector line makes the build complete cleanly with no other changes:

CFLAGS += -fno-schedule-insns2
CFLAGS += -fno-schedule-insns

This disables GCC's instruction scheduler, which is what's crashing, and the resulting modules load and run normally (system has been up and stable on linux-zen 7.0.12 with both monitors active since applying it).

Why I'm filing here rather than only with GCC: the ICE is ultimately a compiler bug, but _flcnDmemTransfer_LS10 is presumably doing something specific in its codegen shape that's tripping the scheduler — other TUs in the same build compile fine at the same -O2. A small source-side tweak (or shipping the -fno-schedule-insns* guard conditionally for affected GCC versions in the upstream Makefile) would unblock everyone on bleeding-edge toolchains immediately, without waiting on a GCC point release to land in distro repos.

Toolchain versions for reference:

• gcc 16.1.1+r12+g301eb08fa2c5-1 (Arch)
• linux-zen 7.0.12.zen1-1 with matching linux-zen-headers
• nvidia-open-dkms 610.43.02-2
• dkms 3.2.4

I have not tested whether the proprietary (closed) 610.43.02 driver hits the same ICE; the offending source file lives in common/nvswitch/ which is shared between the open and closed builds, so I'd expect it to.