https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90654
Bug ID: 90654 Summary: GCC doesn't value-initialize base class with trivial default constructor, resulting in uninitialized data Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: adrianbibbywalther at gmail dot com Target Milestone: --- Created attachment 46422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46422&action=edit Source code reproducing the bug. g++ -v produces the following: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=d:/mingw/custom/compilers/gnu/install/bin/../libexec/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../gcc-8.3.0/configure --prefix=/d/MinGW/Custom/Compilers/gnu/install --with-gmp=/d/MinGW/Custom/Compilers/gnu/deps-install --with-mpfr=/d/MinGW/Custom/Compilers/gnu/deps-install --with-mpc=/d/MinGW/Custom/Compilers/gnu/deps-install --with-isl=/d/MinGW/Custom/Compilers/gnu/deps-install --disable-nls --enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-libgomp --disable-libstdcxx-verbose --disable-win32-registry --enable-threads=posix --with-sysroot=/d/MinGW/Custom/Compilers/gnu/install --disable-shared --enable-static CFLAGS='-g0 -O3' 'BOOT_CFLAGS=-g0 -O3' 'CFLAGS_FOR_TARGET=-g0 -O3' CXXFLAGS='-g0 -O3' 'BOOT_CXXFLAGS=-g0 -O3' 'CXXFLAGS_FOR_TARGET=-g0 -O3' Thread model: posix gcc version 8.3.0 (GCC) The command line g++ -O3 bug.cpp reproduces the bug in short easy to read, and clearly wrong, assembly. Namely it reads an uninitialized variable. -Wall -Wextra reports the variable as uninitialized, which it is, and the bug is that it shouldn't be. They are a good indication of whether a particular code sample triggers the bug. -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined have no effect on the output whatsoever. I have also replicated the bug using the versions of 8.3 and 9.1 on <https://godbolt.org/>, so it is not a bug exclusive to MinGW. It is worth noting it is incredibly fiddle, whether it produces the wrong assembly or not. The attached code always fails, but slight variations correctly return 0, although -Wall still reports a warning.