https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124477
--- Comment #4 from Robert Broglia <robert.broglia at gmail dot com> --- Thanks Nathaniel, it looks like the ICE is indeed related to GLIBC and specifically when the definitions in bits/string_fortified.h are used. The specific flags that trigger whether this header is included allow reproducing the bug, for example even if -O3 is set with -fsanitize=address the header isn't included and no ICE occurs. Explicitly setting _FORTIFY_SOURCE=0 also avoids the ICE even with -O3. Here are some example results from the test code you posted: g++ -fmodules -S -O3 a.cpp b.cpp # ICE g++ -fmodules -S -O3 -fsanitize=address a.cpp b.cpp # No ICE g++ -fmodules -S -O3 -D_FORTIFY_SOURCE=1 a.cpp b.cpp # ICE g++ -fmodules -S -O3 -D_FORTIFY_SOURCE=0 a.cpp b.cpp # No ICE Above I've attached the bug report output from the _FORTIFY_SOURCE=1 case on both GCC 16 and 15, I'm on GLIBC 2.43 for reference. Thanks for looking into this and let me know if you need any other info.
