https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126773
Bug ID: 126773
Summary: gcc 17 experimental ICE on Windows target when LTO
compile contains uninitialized global
__stack_chk_guard
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: tanksherman27 at gmail dot com
Target Milestone: ---
While compiling a source file I ran into the following ICE, using gcc 17
experimental:
during IPA pass: modref
stack_chk_guard.c:7:1: internal compiler error: in write_symbol, at
lto-streamer-out.cc:3370
7 | }
| ^
0x41b341cc internal_error(char const*, ...)
../../../../eclipse-committers-2023-12-R-win32-x86_64/Workspace/gcc/gcc/gcc/diagnostic-global-context.cc:787
0x41b342bd fancy_abort(char const*, int, char const*)
../../../../eclipse-committers-2023-12-R-win32-x86_64/Workspace/gcc/gcc/gcc/diagnostics/context.cc:1813
0x407dbb9b write_symbol(streamer_tree_cache_d*, tree_node*, hash_set<char
const*, false, default_hash_traits<char const*> >*, bool) [clone .constprop.0]
../../../../eclipse-committers-2023-12-R-win32-x86_64/Workspace/gcc/gcc/gcc/lto-streamer-out.cc:3370
0x406b0d69 ipa_write_summaries()
../../../../eclipse-committers-2023-12-R-win32-x86_64/Workspace/gcc/gcc/gcc/lto-streamer-out.cc:3474
0x403a89e2 symbol_table::compile()
../../../../eclipse-committers-2023-12-R-win32-x86_64/Workspace/gcc/gcc/gcc/cgraphunit.cc:2292
I managed to manually reduce the offending source file down to
unsigned int __stack_chk_guard;
__attribute__((__constructor__))
static void __attribute__((__cdecl__)) init(void) {
if (__stack_chk_guard != 0)
return;
}
Compile this with the minimal command line of gcc.exe -m32 -pipe -std=gnu99
-fno-builtin -flto=auto -fuse-linker-plugin -ffat-lto-objects -c -o
stack_chk_guard.o stack_chk_guard.c to get the ICE. This also affects 64 bit,
replace the unsigned int with unsigned long long in the reduced program and
replace -m32 with -m64 in the command line and you will get the same ICE.
It appears to be because the global __stack_chk_guard is used in the init
method but __stack_chk_guard itself is not defined, only declared. I am unsure
how serious this bug is and whether it is an indication of a bigger problem, so
I decided to report it just in case. Initializing __stack_chk_guard with any
value, such as the default 0xdeadbeef, makes the ICE go away, but I think there
is likely good reason why it is not initialized directly in this case.
The compiler was configured as
../../../eclipse-committers-2023-12-R-win32-x86_64/Workspace/gcc/gcc/configure
--prefix=/c/Users/vertig0/Downloads/Windows/gcc
--with-sysroot=/c/Users/vertig0/Downloads/Windows/gcc
--with-native-system-header-dir=/x86_64-w64-mingw32/include
--with-build-config=bootstrap-lto --enable-bootstrap --enable-checking=release
--enable-mingw-wildcard --enable-languages=c,c++,lto --enable-shared
--enable-static --enable-libatomic --enable-threads=win32 --enable-tls
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-backtrace
--enable-libstdcxx-threads --enable-libstdcxx-filesystem-ts
--enable-libstdcxx-time --disable-libgomp --disable-libssp --disable-rpath
--disable-nls --disable-werror --disable-symvers --with-libiconv
--with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-gnu-as --with-gnu-ld --with-libstdcxx-zoneinfo --enable-plugin
--enable-lto
I imagine the compiler configuration doesn't matter much in this bug, however.
