This is the mail archive of the gdb-testers@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] gdb: Disable -Werror for -Wmaybe-uninitialized


*** TEST RESULTS FOR COMMIT e13cb306f099a8cd450c9fba0dfa22521aaa3c95 ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: e13cb306f099a8cd450c9fba0dfa22521aaa3c95

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]