diff options
author | Pedro Alves <palves@redhat.com> | 2017-05-05 01:03:28 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2017-05-05 01:03:28 +0100 |
commit | e13cb306f099a8cd450c9fba0dfa22521aaa3c95 (patch) | |
tree | 31e4cbe4dc7ac222690ed90eb27e1cddaf3cc2f6 /zlib/example.c | |
parent | 323449189c3474d1ab352b49172f4f59670ea73e (diff) | |
download | gdb-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