[Bug c++/90654] New: GCC doesn't value-initialize base class with trivial default constructor, resulting in uninitialized data

[adrianbibbywalther at gmail dot com]

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.