]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/gdbserver/ChangeLog
gdb: Disable -Werror for -Wmaybe-uninitialized
authorPedro Alves <palves@redhat.com>
Fri, 5 May 2017 00:03:28 +0000 (01:03 +0100)
committerPedro Alves <palves@redhat.com>
Fri, 5 May 2017 00:03:28 +0000 (01:03 +0100)
commite13cb306f099a8cd450c9fba0dfa22521aaa3c95
tree31e4cbe4dc7ac222690ed90eb27e1cddaf3cc2f6
parent323449189c3474d1ab352b49172f4f59670ea73e
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.
gdb/ChangeLog
gdb/configure
gdb/gdbserver/ChangeLog
gdb/gdbserver/configure
gdb/warning.m4