aboutsummaryrefslogtreecommitdiff
path: root/zlib/example.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2017-05-05 01:03:28 +0100
committerPedro Alves <palves@redhat.com>2017-05-05 01:03:28 +0100
commite13cb306f099a8cd450c9fba0dfa22521aaa3c95 (patch)
tree31e4cbe4dc7ac222690ed90eb27e1cddaf3cc2f6 /zlib/example.c
parent323449189c3474d1ab352b49172f4f59670ea73e (diff)
downloadgdb-e13cb306f099a8cd450c9fba0dfa22521aaa3c95.zip
gdb-e13cb306f099a8cd450c9fba0dfa22521aaa3c95.tar.gz
gdb-e13cb306f099a8cd450c9fba0dfa22521aaa3c95.tar.bz2
gdb: Disable -Werror for -Wmaybe-uninitialized
Newer GCCs are triggering false-positive -Wmaybe-uninitialized warnings around code that uses gdb::optional: https://sourceware.org/ml/gdb-patches/2017-05/msg00118.html Using std::optional wouldn't help, it triggers the same warnings: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Initializing the variables to quiet the warning would defeat the purpose of gdb::optional. Making the optional ctor memset its storage would be a pessimization. Wrapping gdb::optional's internals with "#pragma GCC diagnostic push/ignored/pop" doesn't work, we'd have to wrap uses of gdb::optional instead, which I think would get unwieldy and ugly as we start using gdb::optional more and more. The -Wmaybe-uninitialized warning is documented as producing false positives (unlike -Wuninialized), so until we find a better workaround, disable -Werror for this warning. You'll still see the warning when building gdb, but it won't cause a build failure. Tested by building with gcc 4.8.5, 5.3.1, and gcc trunk (20170428). gdb/ChangeLog: 2017-05-05 Pedro Alves <palves@redhat.com> * warning.m4 (build_warnings): Add -Wno-error=maybe-uninitialized. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2017-05-05 Pedro Alves <palves@redhat.com> * configure: Regenerate.
Diffstat (limited to 'zlib/example.c')
0 files changed, 0 insertions, 0 deletions